RegExps that don't modify global state?

Steve Fink sphink at gmail.com
Tue Sep 16 22:35:36 PDT 2014


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
> <mailto: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.

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.

>
> 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 <mailto: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 <mailto: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 <mailto:es-discuss at mozilla.org>
>>         https://mail.mozilla.org/listinfo/es-discuss
>>
>>     ,
>>
>>     _______________________________________________
>>     es-discuss mailing list
>>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>     https://mail.mozilla.org/listinfo/es-discuss
>>
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto: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/20140916/4871b6ca/attachment-0001.html>


More information about the es-discuss mailing list