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

Unicode and JSLint

Expand Messages
  • abyssoft@ymail.com
    As Described in ECMA-262 3rd Edition JSLint fails to support Rules for Variable names as laid out in section 7.3 on page 14-15 where... Identifier ::
    Message 1 of 5 , Aug 5, 2010
    View Source
    • 0 Attachment
      As Described in ECMA-262 3rd Edition JSLint fails to support Rules for Variable names as laid out in section 7.3 on page 14-15 where...

      Identifier ::
      IdentifierName but not ReservedWord

      IdentifierName ::
      IdentifierStart
      IdentifierName IdentifierPart

      IdentifierStart ::
      UnicodeLetter
      $
      _
      \ UnicodeEscapeSequence

      IdentifierPart ::
      IdentifierStart
      UnicodeCombiningMark
      UnicodeDigit
      UnicodeConnectorPunctuation
      \ UnicodeEscapeSequence

      UnicodeLetter
      any character in the Unicode categories "Uppercase letter (Lu)", "Lowercase letter (Ll)", "Titlecase letter (Lt)",
      "Modifier letter (Lm)", "Other letter (Lo)", or "Letter number (Nl)".
      UnicodeCombiningMark
      any character in the Unicode categories "Non-spacing mark (Mn)" or "Combining spacing mark (Mc)"
      UnicodeDigit
      any character in the Unicode category "Decimal number (Nd)"
      UnicodeConnectorPunctuation
      any character in the Unicode category "Connector punctuation (Pc)"
      UnicodeEscapeSequence
      see 7.8.4.

      fails to support any or \ UnicodeEscapeSequence, UnicodeLetter, UnicodeCombiningMark when present in identifier names.
      while for English these may not be the most desired, it should still be support as it is legitimate and in for those who are non english speakers usage of unicode characters would be normal to reflect their language.
    • Douglas Crockford
      ... It isn t a matter of legitimacy, it is a matter of portability. I have not found that the forms you are demanding are actually used in the wild except by
      Message 2 of 5 , Aug 23, 2010
      View Source
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, "abyssoft@..." <abyssoft@...> wrote:
        >
        > As Described in ECMA-262 3rd Edition JSLint fails to support Rules for Variable names as laid out in section 7.3 on page 14-15 where...
        >
        > Identifier ::
        > IdentifierName but not ReservedWord
        >
        > IdentifierName ::
        > IdentifierStart
        > IdentifierName IdentifierPart
        >
        > IdentifierStart ::
        > UnicodeLetter
        > $
        > _
        > \ UnicodeEscapeSequence
        >
        > IdentifierPart ::
        > IdentifierStart
        > UnicodeCombiningMark
        > UnicodeDigit
        > UnicodeConnectorPunctuation
        > \ UnicodeEscapeSequence
        >
        > UnicodeLetter
        > any character in the Unicode categories "Uppercase letter (Lu)", "Lowercase letter (Ll)", "Titlecase letter (Lt)",
        > "Modifier letter (Lm)", "Other letter (Lo)", or "Letter number (Nl)".
        > UnicodeCombiningMark
        > any character in the Unicode categories "Non-spacing mark (Mn)" or "Combining spacing mark (Mc)"
        > UnicodeDigit
        > any character in the Unicode category "Decimal number (Nd)"
        > UnicodeConnectorPunctuation
        > any character in the Unicode category "Connector punctuation (Pc)"
        > UnicodeEscapeSequence
        > see 7.8.4.
        >
        > fails to support any or \ UnicodeEscapeSequence, UnicodeLetter, UnicodeCombiningMark when present in identifier names.
        > while for English these may not be the most desired, it should still be support as it is legitimate and in for those who are non english speakers usage of unicode characters would be normal to reflect their language.


        It isn't a matter of legitimacy, it is a matter of portability. I have not found that the forms you are demanding are actually used in the wild except by crackers. If you want your program to be useful to the greatest number of people, you should, perhaps regrettably, stick with the ASCII set of lower case letters for variables names.
      • abyssoft@ymail.com
        Mr. Crockford, I concede that I do see your point; but, at the same time is it not likely that without JSLint supporting in part some of the nearby Unicode
        Message 3 of 5 , Aug 23, 2010
        View Source
        • 0 Attachment
          Mr. Crockford,

          I concede that I do see your point; but, at the same time is it not likely that without JSLint supporting in part some of the nearby Unicode blocks that it is unlikely to see them appear in use.
          I would think that initially: "Latin-1 Supplement", "Latin Extended-A", "Latin Extended-B", "Greek and Coptic", and "Cyrillic" would be good for initial expansion.
          I admit that my primary desire for usage of Unicode is a bit eccentric in that I was hoping to be able to use the "Letterlike Symbols" block for a math lib as these are useful for such. I will stick with ASCII for the time being and only use the other Unicode chars for strings and comments. Your opinion is one that I value highly.

          Sincerely,
          George W
        • Cheney, Edward A SSG RES USAR
          George, To be fair it is unlikely that Unicode will become a functional part of the web, content aside, until RFC 3897 gains some traction over RFC 3896, which
          Message 4 of 5 , Aug 25, 2010
          View Source
          • 0 Attachment
            George,

            To be fair it is unlikely that Unicode will become a functional part of the web, content aside, until RFC 3897 gains some traction over RFC 3896, which is not going to happen for a very long time since HTTP is inherently reliant upon RFC 3986. Dr. Fielding appears to have no ambition to introduce additional complexity into the processing of HTTP header definitions that would exist in a more I18N environment. As a result it is quite probable that ASCII, particularly 7-bit ASCII, will remain the character set of web code for years to come. At the same time it does not appear other bodies, such as IMC or the groups managed under ISOC, of the Internet's application layer particularly have any such interest either.

            Austin
          • abyssoft@ymail.com
            Austin, Point well taken. And, thank you for the explanation. It clarify the why and the when. George
            Message 5 of 5 , Aug 25, 2010
            View Source
            • 0 Attachment
              Austin,

              Point well taken. And, thank you for the explanation. It clarify the why and the when.

              George

              --- In jslint_com@yahoogroups.com, "Cheney, Edward A SSG RES USAR" <austin.cheney@...> wrote:
              >
              > George,
              >
              > To be fair it is unlikely that Unicode will become a functional part of the web, content aside, until RFC 3897 gains some traction over RFC 3896, which is not going to happen for a very long time since HTTP is inherently reliant upon RFC 3986. Dr. Fielding appears to have no ambition to introduce additional complexity into the processing of HTTP header definitions that would exist in a more I18N environment. As a result it is quite probable that ASCII, particularly 7-bit ASCII, will remain the character set of web code for years to come. At the same time it does not appear other bodies, such as IMC or the groups managed under ISOC, of the Internet's application layer particularly have any such interest either.
              >
              > Austin
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.