On 09/16/2014 10:13 PM, Jussi Kalliokoski wrote: > On Wed, Sep 17, 2014 at 3:21 AM, Alex Kocharin <a...@kocharin.ru > <mailto:a...@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.giammar...@gmail.com <mailto:andrea.giammar...@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 >> <al...@wirfs-brock.com <mailto:al...@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@mozilla.org <mailto:es-discuss@mozilla.org> >> https://mail.mozilla.org/listinfo/es-discuss >> >> , >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss