Loading ...
Sorry, an error occurred while loading the content.

Re: [jslint] member names outside ASCII but still in the Unicode Basic Multilingual Plane

Expand Messages
  • Luke Page
    I m arguing in favour of the current situation.. for myself, working in English. I should have let someone else for whom it is of benefit argue for anything
    Message 1 of 14 , Jan 6, 2012
    • 0 Attachment
      I'm arguing in favour of the current situation.. for myself, working in
      English.

      I should have let someone else for whom it is of benefit argue for anything
      different.
      On Jan 6, 2012 9:26 PM, "douglascrockford" <douglas@...> wrote:

      > **
      >
      >
      > --- In jslint_com@yahoogroups.com, Luke Page <luke.a.page@...> wrote:
      >
      > > For a real world example, I've seen a bug where an identifier had a �
      > (crylic
      > > c) in it written by a russian coder which looked in most fonts the same
      > as
      > > c..
      > >
      > > Still I think it would be nice to not just stamp western standards on
      > > programming.
      >
      > What are you trying to say? You gave us clear evidence of why it shouldn't
      > accept both Cyrillic and Latin. So are you arguing that JSLint should only
      > accept Cyrillic?
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Rob Richardson
      Programming in general is done in English. I m sorry to be the dumb American, but that s pretty much how it works. I ve heard from many international
      Message 2 of 14 , Jan 7, 2012
      • 0 Attachment
        Programming in general is done in English. I'm sorry to be the dumb
        American, but that's pretty much how it works. I've heard from many
        international programmers that using localized versions of developer tools
        or code documentation is ineffective, and that for as much as English is not
        their native tongue, English is their preferred programming metaphor. Thus
        constraining non-string content to ASCII only is likely not a hindrance to
        many. Perhaps the "bug" is that we've learned some since the book was
        published.

        Rob


        -----Original Message-----
        From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
        Behalf Of Luke Page
        Sent: Friday, January 06, 2012 2:40 PM
        To: jslint_com@yahoogroups.com
        Subject: Re: [jslint] member names outside ASCII but still in the Unicode
        Basic Multilingual Plane

        I'm arguing in favour of the current situation.. for myself, working in
        English.

        I should have let someone else for whom it is of benefit argue for anything
        different.
        On Jan 6, 2012 9:26 PM, "douglascrockford" <douglas@...> wrote:

        > **
        >
        >
        > --- In jslint_com@yahoogroups.com, Luke Page <luke.a.page@...> wrote:
        >
        > > For a real world example, I've seen a bug where an identifier had a
        > > Ñ
        > (crylic
        > > c) in it written by a russian coder which looked in most fonts the
        > > same
        > as
        > > c..
        > >
        > > Still I think it would be nice to not just stamp western standards
        > > on programming.
        >
        > What are you trying to say? You gave us clear evidence of why it
        > shouldn't accept both Cyrillic and Latin. So are you arguing that
        > JSLint should only accept Cyrillic?
        >
        >
        >


        [Non-text portions of this message have been removed]



        ------------------------------------

        Yahoo! Groups Links
      • Brennan
        I m afraid that I don t accept that s the way it s always been or variants as a strong argument. Especially when exceptions can be so readily found. But OK,
        Message 3 of 14 , Feb 24, 2012
        • 0 Attachment
          I'm afraid that I don't accept "that's the way it's always been" or
          variants as a strong argument. Especially when exceptions can be so
          readily found.
          But OK, if I may restate the problem as I now understand it, with some
          finer nuances:
          We have a Latin "A" (U+0041) is distinct from the Cyrillic "А"
          (U+0410) and the Greek alpha "Î`" (U+0391). They look identical, but
          have different code points. So, going outside of ascii when naming
          identifiers could cause name-mismatch bugs which would be very difficult
          to spot. This is indeed a good reason for not accepting those
          characters.
          (They look identical as long as they haven't been mangled by passing
          through some non-unicode system along the way, which appears to be
          happening with some of the posts on this thread, and maybe this one too.
          This is a separate problem, and should have no bearing on how jslint
          behaves or ought to behave. BTW I notice that the web yahoo groups plain
          text editor interface is not doing 'the right thing' to my non-ascii
          chars when I preview this message, so I have switched to rich text.
          Let's see what happens after I send it).
          But while I respect the basic logic and simple pragmatism of rejecting
          all non-ascii characters, there must surely be a subset of the basic
          multilingual plane where the non-ascii glyphs do not resemble any
          others, and therefore would be 'safe' to code with. Is this a reasonable
          suggestion?
          For example, I would like to feel free to use θ (lower case theta,
          entity θ) for angles (as mathematicians have done for thousands of
          years), and there are dozens of other non-ascii characters - mostly
          Greek - which are conventionally used in various problem domains.
          Theta appears four times in the basic multilingual plane:
          Θ or entity Θ ( U+0398)θ or entity θ (U+03B8)Ï`
          or entity ϑ (U+03D1)Ï´ or entity ϴ (U+03F4)
          All four forms are clearly distinct from one another. To my eyes they
          are at least as distinct as 1 and I and | and l or O and 0 in ascii. And
          they do not resemble any other glyphs, least of all those found in
          ascii.
          I can see no good reason why such characters should not be tolerated by
          jslint. (Except perhaps that jslint may be bloated with some kind of
          lookup table, and - of course - some work always takes more time than no
          work).
          Another suggestion would be to make it an *option* to tolerate
          characters that fall outside of ascii.
          If I am so perversely traditional (or radical and progressive) that I
          insist on using θ in my trigonometry script, then I would hope that
          I know what I am doing. This is not a matter of having my feelings hurt.
          Rather it seems misleading for jslint to tell me that I did something
          'unexpected', when the truth of the matter is that I did something that
          jslint does indeed expect would cause a very particular (but
          unmentioned) problem. A problem which (in the case of θ) would never
          happen.


          [Non-text portions of this message have been removed]
        • Tom Worster
          ... this leads to a need for a standard resembles($char1, $char2) function. but resemblance is subjective. the ICU SpoofChecker?
          Message 4 of 14 , Feb 24, 2012
          • 0 Attachment
            On 2/24/12 4:46 AM, "Brennan" <brennan@...> wrote:

            >But while I respect the basic logic and simple pragmatism of rejecting
            >all non-ascii characters, there must surely be a subset of the basic
            >multilingual plane where the non-ascii glyphs do not resemble any
            >others, and therefore would be 'safe' to code with. Is this a reasonable
            >suggestion?

            this leads to a need for a standard resembles($char1, $char2) function.
            but resemblance is subjective.

            the ICU SpoofChecker?
          Your message has been successfully submitted and would be delivered to recipients shortly.