Sorry, none of these examples are persuasive. Such non-local causality is a nightmare on many grounds. If we did want to provide equivalent functionality somehow, we should find a non-stupid way to package it.
I like Claude's proposal as stated: Annex B normative *optional*, configurable and actually deletable, no contamination of cross-realm or subclasses. The only reason to admit even that is legacy. Claude's proposal is a clean proposal that accommodates legacy while minimizing further impact. On Tue, Apr 26, 2016 at 9:50 PM, Andrea Giammarchi < [email protected]> wrote: > My 2 cents. > > I always had the feeling people complaining about `RegExp.$1` and friends > never really used them. > > For instance, your example: > > ```js > /(a)/.exec('a') > Object.keys(bar) > RegExp.$1 > ``` > > might have side effects but it's also made up and, I believe, not a > real-world concern. > If you use `re.exec` you address it, otherwise you go `re.test` while if > you use `re.test` you (or at least *me*) are aware of possible side effects > and will use the `RegExp.$1` or other property *instantly* after. > > Following just a simple example: > > ```js > if (/^item-(\d+)$/.test(id)) { > let num = parseInt(RegExp.$1, 10); > // the rest of the code > } > ``` > > I'm not saying these properties are cool, always safe, or anything, I'm > just saying there are few useful cases for them. > > However, while I agree the problem is that these modify the globally > shared constructor, I also think that having these magic properties > available in a subclass only, would be probably the key to solve pretty > much all problems described in that page. > > ```js > reg.exp = class extends RegExp {}; > function reg(source, ...flags) { > return typeof source === 'string' ? > new reg.exp(...[source, ...flags]) : > new reg.exp(source.source, source.flags); > } > > if (reg(/^item-(\d+)$/).test(id)) { > let num = parseInt(reg.exp.$1, 10); > // the rest of the code > > RegExp.$1 === reg.exp.$1; // false > // the extended RegExp didn't modify > // the global RegExp > } > ``` > > Of course this would still suffer same, or very similar, problems in case > `re.class` is exported as module and consumed by many different libraries, > but I would be surprised if subclassing `RegExp` will create a limited > subset or, at least, I wouldn't call that an extend. > > After all, if "safe" is the main concern, writing `class SRegExp extends > RegExp {}` on top of a module that uses RegExp in various ways doesn't look > like a big piece of extra code to write, it's like a function declaration > and it will make your code immune from global RegExp gotchas. > > Or ... doesn't it? > > Best Regards > > > > > > > > > > On Tue, Apr 26, 2016 at 7:20 PM, Claude Pache <[email protected]> > wrote: > >> Hi, >> >> About the bad old nonstandard RegExp functionalities: >> >> * `RegExp.prototype.compile()` — currently in Annex B; >> * `RegExp.$1`, `RegExp.leftContext`, etc. — currently unspecced. >> >> Although we could probably not get rid of them for plain regexps, I think >> it is a good idea to disable them for proper subclasses of RegExp (e.g., >> `class MyRegExp extends RegExp {}`). >> >> Basically, the reason is that these methods break encapsulation (they >> operate on the raw regexp), leading to potential bugs when using them. >> Moreover `RegExp.$1` and friends have the additional troublesome property >> of relying on a global state that could be unexpectedly modified. For >> concrete examples of what could go wrong, see the >> subclass-restriction-motivation.md subpage in the proposal linked below. >> >> Here is a link to a possible specification for the regexp statics >> (RegExp.$1, ...), that includes the disabling of bad legacy features for >> proper subclasses of RegExp (and for some edge-cases around cross-realm >> interactions): >> >> https://github.com/claudepache/es-regexp-legacy-static-properties >> >> What do you think? Are implementations willing to try? >> >> —Claude >> >> >> _______________________________________________ >> 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 > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
