What's the advantage of `re.test(str); RegExp.$1` over `let m=re.match(str); m[1]`?
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" <[email protected]>:
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).RegardsP.S. there's no such thing as RegExp.$0 but RegExp['$&'] will provide the (probably) intended resultP.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 <[email protected]> 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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
