RegExps that don't modify global state?

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Wed Sep 17 00:56:10 PDT 2014


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140917/a42dc12d/attachment.html>


More information about the es-discuss mailing list