Disabling nonstandard RegExp functionalities for proper subclasses of RegExp

Mark S. Miller erights at google.com
Wed Apr 27 15:39:27 UTC 2016


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 <
andrea.giammarchi at gmail.com> 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 <claude.pache at gmail.com>
> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160427/ce1fd568/attachment-0001.html>


More information about the es-discuss mailing list