On 09/16/2014 10:13 PM, Jussi Kalliokoski wrote:
> On Wed, Sep 17, 2014 at 3:21 AM, Alex Kocharin <[email protected]
> <mailto:[email protected]>> 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"
> <[email protected] <mailto:[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).
>>
>> 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
>> <[email protected] <mailto:[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] <mailto:[email protected]>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> ,
>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected] <mailto:[email protected]>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> es-discuss mailing list
> [email protected] <mailto:[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
