RegExps that don't modify global state?

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Sep 17 01:02:23 PDT 2014


you could obtain that inside a `with` statement :P

```js
with(RegExp) {
  if (/r(\d)d(\d)/i.test('R2D2')) {
    '22' === $1 + $2;
  }
}
```

Regards


On Wed, Sep 17, 2014 at 8:56 AM, Jussi Kalliokoski <
jussi.kalliokoski at gmail.com> wrote:

> On Wed, Sep 17, 2014 at 8:35 AM, Steve Fink <sphink at gmail.com> wrote:
>
>>  On 09/16/2014 10:13 PM, Jussi Kalliokoski wrote:
>>
>> On Wed, Sep 17, 2014 at 3:21 AM, Alex Kocharin <alex at kocharin.ru> wrote:
>>
>>>
>>> What's the advantage of `re.test(str); RegExp.$1` over `let
>>> m=re.match(str); m[1]`?
>>>
>>
>>  Nothing. However, with control structures it removes a lot of
>> awkwardness:
>>
>> * `if ( /foo:(\d+)/.test(str) && parseInt(RegExp.$1, 10) > 15 ) { ...`
>>  * `if ( /name: (\w+)/).test(str) ) { var name = RegExp.$1; ...`
>>
>>
>> Is
>>
>>   if ((m = /foo:(\d+)/.exec(str)) && parseInt(m[1], 10) > 15) { ... }
>>
>> so bad? JS assignment is an expression; make use of it. Much better than
>> Python's refusal to allow such a thing, requiring indentation trees of doom
>> or hacky workarounds when you just want to case-match a string against a
>> couple of regexes.
>>
>
> Looks pretty confusing, and my linter agrees (assignment in an if
> statement is most likely a bug). Also that doesn't do the same thing, it
> assigns to global m, unless you var it before the if(), so more noise,
> especially when this if() is an else if() in a set of if() statements.
>
> But this boils down to taste in linter rules and other bias for what is
> pretty and what is not, which is not a very interesting discussion. My main
> point was that the /u flag shouldn't disable this feature as a side effect.
>
>
>> The global state *is* bad, and you don't need turns or parallelism to be
>> bitten by it.
>>
>> function f(s) {
>>   if (s.test(/foo(\d+/)) {
>>     print("Found in " + formatted(s));
>>     return RegExp.$1; // Oops! formatted() does a match internally.
>>   }
>> }
>>
>> Global variables are bad. They halfway made sense in Perl, but even the
>> Perl folks wish they'd been lexical all along.
>>
>
> No argument here, I have no use for the RegExp.$ things being global. I'd
> much rather have them lexical, e.g. `if ( /name: (\w+)/.test(str) ) { let
> name = $1; ...` but that ship's sailed and even if we wanted to introduce
> that now as a part of the "disable global state modification" flag (which
> would be awesome), it would have a lot of things that need to be thought
> through to make it happen and I doubt anyone's willing to champion that
> effort.
>
>
>>
>>
>>
>>  I personally find this functionality very useful and would be saddened
>> if /u which I want to use all of the sudden broke this feature. Say what
>> you mean. Unicode flag disabling features to enable parallelism is another
>> footnote for WTFJS.
>>
>>
>>>
>>> I assume RegExp["$'"] and RegExp["$`"] are nice to have, I remember them
>>> from perl, but never actually used them in javascript.
>>>
>>>
>>> 16.09.2014, 23:03, "Andrea Giammarchi" <andrea.giammarchi at gmail.com>:
>>>
>>> I personally find the `re.test(str)` case a good reason to keep further
>>> access to `RegExp.$1` and others available instead of needing to test
>>> **and** grab eventually a match (redundant, slower, etc)
>>>
>>> As mentioned already `/u` will be used by default as soon as supported;
>>> having this implicit opt-out feels very wrong to me since `/u` meaning is
>>> completely different.
>>>
>>> Moreover, AFAIK JavaScript is single threaded per each EventLoop so I
>>> don't see conflicts possible if parallel execution is performed elsewhere,
>>> where also globals will (will them?) be a part, as every
>>> sandbox/iframe/worker has worked until now.
>>>
>>> I'd personally +1 an explicit opt-out and indifferently accept a re-opt
>>> as modifier such `/us` where `s` would mean stateful (or any other char
>>> would do as long as `RegExp.prototype.test` won't loose it's purpose and
>>> power).
>>>
>>> Regards
>>>
>>> P.S. there's no such thing as RegExp.$0 but RegExp['$&'] will provide
>>> the (probably) intended result
>>>  P.S. to know more about RegExp and these proeprties my old slides from
>>> BerlinJS event should do:
>>> http://webreflection.blogspot.co.uk/2012/02/berlin-js-regexp-slides.html
>>>
>>> On Tue, Sep 16, 2014 at 7:35 PM, Allen Wirfs-Brock <
>>> allen at wirfs-brock.com> wrote:
>>>
>>>
>>> On Sep 16, 2014, at 11:16 AM, Domenic Denicola wrote:
>>>
>>> > I had a conversation with Jaswanth at JSConf EU that revealed that
>>> RegExps cannot be used in parallel JS because they modify global state,
>>> i.e. `RegExp.$0` and friends.
>>> >
>>> > We were thinking it would be nice to find some way of getting rid of
>>> this wart. One idea would be to bundle the don't-modify-global-state
>>> behavior with the `/u` flag. Another would be to introduce a new flag to
>>> opt-out. The former is a bit more attractive since people will probably
>>> want to use `/u` all the time anyway. I imagine there might be other
>>> possibilities others can think of.
>>> >
>>> > I also noticed today that the static `RegExp` properties are not
>>> specced, which seems at odds with our new mandate to at least Annex B-ify
>>> the required-for-web-compat stuff.
>>>
>>> Yes, they should be in Annex B.  But that means that somebody needs to
>>> write a spec. that defines their behavior.
>>>
>>> We could then add that extension to clause 16.1 as being forbidden for
>>> RegExps created with the /u flag.
>>>
>>> Allen
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>  ,
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140917/3fd784c6/attachment.html>


More information about the es-discuss mailing list