RegExps that don't modify global state?

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Sep 16 12:03:42 PDT 2014


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


More information about the es-discuss mailing list