heh - apparently there's a completely different jas in the js world that was also affected by global state in RegExp (this is the one that bit me http://code.google.com/p/google-caja/wiki/RegexpsLeakMatchGlobally).
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 had a quick look at http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism. Without commenting on the virtues or shortcomings of the proposed semantics, the conflict appears to be due to the order in which turns occur even if any turn runs to completion as a results of the new parallel primitives being introduced. This is because of the way elemental functions are defined to be "temporally immutable" viz. "Any EcmaScript function can be used as long as it has an appropriate signature and is temporally immutable, i.e., the function is side effect free and does not mutate global state". Presumably by this definition regex matching is not side-effect free. -- Jasvir Nagra On Tue, Sep 16, 2014 at 6:22 PM, Brendan Eich <[email protected]> wrote: > Alex Kocharin wrote: > >> What's the advantage of `re.test(str); RegExp.$1` over `let >> m=re.match(str); m[1]`? >> > > Right. I think Andrea is smoking something :-P. > > I assume RegExp["$'"] and RegExp["$`"] are nice to have, I remember them >> from perl, but never actually used them in javascript. >> > > I regret them. It was the '90s, dynamicly scoped $-vars in Perl seemed > "useful". > > /be > _______________________________________________ > 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
