Re: [jslint] member names outside ASCII but still in the Unicode Basic Multilingual Plane
- 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
But OK, if I may restate the problem as I now understand it, with some
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
(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
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
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
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
[Non-text portions of this message have been removed]
- On 2/24/12 4:46 AM, "Brennan" <brennan@...> wrote:
>But while I respect the basic logic and simple pragmatism of rejectingthis leads to a need for a standard resembles($char1, $char2) function.
>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
but resemblance is subjective.
the ICU SpoofChecker?