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

Re: [jslint] regex parsing - [^]

Expand Messages
  • Ben White
    If you read the documentation on mozilla.org you will find [^] as their suggested any character expression Ben ... [Non-text portions of this message have
    Message 1 of 13 , Jan 18, 2013
    • 0 Attachment
      If you read the documentation on mozilla.org you will find [^] as their
      suggested "any character" expression

      Ben
      On Jan 18, 2013 4:28 AM, "Luke Page" <luke.a.page@...> wrote:

      > **
      >
      >
      > Hi,
      >
      > My colleague was linting this and getting an error
      >
      > var a = /<.+>[^]<.+>/;
      >
      > Unescaped '^'.
      >
      > He argued that [^] was a valid succinct way of saying "any character"
      > rather than [.\n\r]* or [\s\S]*
      >
      > What do you think?
      >
      > Regards,
      >
      > Luke
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Peter Buckner
      such cleverness isn t valid in other regex languages, so it would seem to an unfortunate pattern to learn. -- -Peter Buckner ... [Non-text portions of this
      Message 2 of 13 , Jan 18, 2013
      • 0 Attachment
        such cleverness isn't valid in other regex languages, so it would seem to an unfortunate pattern to learn.
        --
        -Peter Buckner

        On Jan 18, 2013, at 7:01 AM, Luke Page wrote:

        > I think it looks like an error if you haven't come across it before, but
        > once you have, it is probably quite understandable.
        >
        > You could argue that it could be a mistake and the programmer missed off
        > the character class, but I'm not sure that would be a common/predictable
        > mistake.
        >
        > I wondered whether the above was a known pattern for people who do a lot of
        > regex's ?
        >


        [Non-text portions of this message have been removed]
      • george_weilenmann
        Can you point me to the specific link, page, paragraph etc. where this is spec d, I looked on mozilla and could not find this suggestion . I wanted to take a
        Message 3 of 13 , Jan 18, 2013
        • 0 Attachment
          Can you point me to the specific link, page, paragraph etc. where this is spec'd, I looked on mozilla and could not find this "suggestion". I wanted to take a look at it in a RegExp validator; and it's not a valid RegExp.

          <.+>[^]<.+>

          ends up being analyzed as follows

          <
          any character, one or more repetitions
          >
          (X) unmatched bracket in character class
          Beginning of line or string
          ]
          <
          any character, one or more repetitions
          >


          --- In jslint_com@yahoogroups.com, Ben White wrote:
          >
          > If you read the documentation on mozilla.org you will find [^] as their
          > suggested "any character" expression
          >
          > Ben
          > On Jan 18, 2013 4:28 AM, "Luke Page" wrote:
          >
          > > **
          > >
          > >
          > > Hi,
          > >
          > > My colleague was linting this and getting an error
          > >
          > > var a = /<.+>[^]<.+>/;
          > >
          > > Unescaped '^'.
          > >
          > > He argued that [^] was a valid succinct way of saying "any character"
          > > rather than [.\n\r]* or [\s\S]*
          > >
          > > What do you think?
          > >
          > > Regards,
          > >
          > > Luke
          > >
          > > [Non-text portions of this message have been removed]
          > >
          > >
          > >
          >
          >
          > [Non-text portions of this message have been removed]
          >
        • Keradus
          2013/1/19 george_weilenmann ... https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/RegExp The character set [^]
          Message 4 of 13 , Jan 18, 2013
          • 0 Attachment
            2013/1/19 george_weilenmann <abyssoft@...>
            > Can you point me to the specific link, page, paragraph etc. where this is
            > spec'd, I looked on mozilla and could not find this "suggestion".

            https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/RegExp
            "The character set [^] can be used to match any character including newlines."

            --
            keradus
          • george_weilenmann
            Thankyou that did not pop out at me when I looked through that document earlier. I would say avoid that pattern as it is not valid RegExp. I think the way they
            Message 5 of 13 , Jan 18, 2013
            • 0 Attachment
              Thankyou that did not pop out at me when I looked through that document earlier. I would say avoid that pattern as it is not valid RegExp.

              I think the way they listed the information lead to erroneous understanding. [^] in that statement was use to symbolically represent the RegExp symbol . ; why they chose to confuse the issue is beyond me. The segment right below that when taken in context with the above helps to make this a little clearer but not much.


              --- In jslint_com@yahoogroups.com, Keradus wrote:
              >
              > 2013/1/19 george_weilenmann
              > > Can you point me to the specific link, page, paragraph etc. where this is
              > > spec'd, I looked on mozilla and could not find this "suggestion".
              >
              > https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/RegExp
              > "The character set [^] can be used to match any character including newlines."
              >
              > --
              > keradus
              >
            • george_weilenmann
              Did a little digging [^] compiles to not null/empty it is a side effect resulting from the spec for RegExp as performed in JavaScript but does not apply to
              Message 6 of 13 , Jan 18, 2013
              • 0 Attachment
                Did a little digging [^] compiles to not null/empty it is a side effect resulting from the spec for RegExp as performed in JavaScript but does not apply to other implementations of RegExp.

                Given that this is unique to JavaScript I'd say that JSLint is in the right as it is confusing.


                --- In jslint_com@yahoogroups.com, Keradus wrote:
                >
                > 2013/1/19 george_weilenmann
                > > Can you point me to the specific link, page, paragraph etc. where this is
                > > spec'd, I looked on mozilla and could not find this "suggestion".
                >
                > https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/RegExp
                > "The character set [^] can be used to match any character including newlines."
                >
                > --
                > keradus
                >
              • Felix E. Klee
                On Sat, Jan 19, 2013 at 3:01 AM, george_weilenmann ... So, which regular expression syntax should JSLint enforce? POSIX? Is that even
                Message 7 of 13 , Jan 19, 2013
                • 0 Attachment
                  On Sat, Jan 19, 2013 at 3:01 AM, george_weilenmann <abyssoft@...>
                  wrote:
                  > Given that this is unique to JavaScript I'd say that JSLint is in the
                  > right as it is confusing.

                  So, which regular expression syntax should JSLint enforce? POSIX? Is
                  that even compatible with the implementation in JavaScript?

                  Given that there are many dialects of regular expressions and not one
                  single authoratitive standard, in my opinion, JSLint should enforce:

                  Regular expressions as defined by ECMAScript. :-)

                  (minus dangerous constructs)
                • douglascrockford
                  ... One of the design principles behind JSLint is that if a feature is problematic, and if it can be completely replaced with another feature that is less
                  Message 8 of 13 , Jan 19, 2013
                  • 0 Attachment
                    --- In jslint_com@yahoogroups.com, "Felix E. Klee" wrote:
                    >
                    > On Sat, Jan 19, 2013 at 3:01 AM, george_weilenmann
                    > wrote:
                    > > Given that this is unique to JavaScript I'd say that JSLint is in the
                    > > right as it is confusing.
                    >
                    > So, which regular expression syntax should JSLint enforce? POSIX? Is
                    > that even compatible with the implementation in JavaScript?
                    >
                    > Given that there are many dialects of regular expressions and not one
                    > single authoratitive standard, in my opinion, JSLint should enforce:
                    >
                    > Regular expressions as defined by ECMAScript. :-)


                    One of the design principles behind JSLint is that if a feature is problematic, and if it can be completely replaced with another feature that is less problematic, then the more problematic feature should not be allowed. In making that determination, the following are irrelevant: It is permitted by a standard. It is sometimes useful. It is totally awesome. It is popular.
                  • John Hawkinson
                    douglascrockford wrote on Sat, 19 Jan 2013 ... It would really help if the documentation explained why [^] was excluded.
                    Message 9 of 13 , Jan 19, 2013
                    • 0 Attachment
                      douglascrockford <douglas@...> wrote on Sat, 19 Jan 2013
                      at 13:20:21 -0000 in <kde6il+8gnb@...>:

                      > One of the design principles behind JSLint is that if a feature is
                      > problematic, and if it can be completely replaced with another
                      > feature that is less problematic, then the more problematic feature
                      > should not be allowed.

                      It would really help if the documentation explained why [^] was
                      excluded.

                      --jhawk@...
                      John Hawkinson
                    • george_weilenmann
                      from http://www.regular-expressions.info/javascript.html JavaScript implements Perl-style regular expressions. However, it lacks quite a number of advanced
                      Message 10 of 13 , Jan 19, 2013
                      • 0 Attachment
                        from http://www.regular-expressions.info/javascript.html

                        JavaScript implements Perl-style regular expressions. However, it lacks quite a number of advanced features available in Perl and other modern regular expression flavors:

                        No \A or \Z anchors to match the start or end of the string. Use a caret or dollar instead.
                        Lookbehind is not supported at all. Lookahead is fully supported.
                        No atomic grouping or possessive quantifiers.
                        No Unicode support, except for matching single characters with \uFFFF.
                        (Note form me on this: only the oldest implementations suffer this limitation today)
                        No named capturing groups. Use numbered capturing groups instead.
                        No mode modifiers to set matching options within the regular expression.
                        No conditionals.
                        No regular expression comments. Describe your regular expression with JavaScript // comments instead, outside the regular expression str

                        [^] is confusing and definitely should be avoided.

                        --- In jslint_com@yahoogroups.com, "Felix E. Klee" wrote:
                        >
                        > On Sat, Jan 19, 2013 at 3:01 AM, george_weilenmann
                        > wrote:
                        > > Given that this is unique to JavaScript I'd say that JSLint is in the
                        > > right as it is confusing.
                        >
                        > So, which regular expression syntax should JSLint enforce? POSIX? Is
                        > that even compatible with the implementation in JavaScript?
                        >
                        > Given that there are many dialects of regular expressions and not one
                        > single authoratitive standard, in my opinion, JSLint should enforce:
                        >
                        > Regular expressions as defined by ECMAScript. :-)
                        >
                        > (minus dangerous constructs)
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.