RegExp.prototype.compile and RegExp instance properties

Brendan Eich brendan at mozilla.com
Tue Jan 15 18:06:57 PST 2013


Mark S. Miller wrote:
> My answer depends on a prior issue. Do we agree that in ES6,
> RegExp.prototype is not itself a RegExp?

Yes, we agreed to that for all the built-ins:

https://mail.mozilla.org/pipermail/es-discuss/2012-September/025301.html 
(thread head)

https://mail.mozilla.org/pipermail/es-discuss/2012-October/025432.html 
(my proposal)

https://bugzilla.mozilla.org/show_bug.cgi?id=797686 (bugzilla bug I need 
to go patch!)

/be

>   Like the Date.prototype and
> WeakMap.prototype we've already talked about, freezing it and
> everything reachable from it must render it immutable, so that it
> isn't a communications channel. SES currently removes
> RegExp.prototype.compile to prevent that communications channel. SES
> includes all variables, properties, and methods normatively defined by
> ES5. I would really like to see it include all of normative ES6
> without violating ocap rules.
>
> If we agree that RegExp.prototype is not a RegExp and the invariant
> breakage of compile were fixed by any of your proposals, then I
> believe we would no longer need to remove it.
>
> Although any of your proposals will then work, I'll suggest a
> variation of your least favorite (#1):
>
> #4: These properties are {writable: false, configurable: true}.
> RegExps may indeed need to be exotic. But they don't refuse freezing.
> Rather, if a RegExp is frozen, or if its properties are individually
> made non-configurable non-writable, then neither compile nor anything
> else can mutate that RegExp. A frozen RegExp (without additional
> properties) is an immutable RegExp. This would be pleasant.
>
>
> On Tue, Jan 15, 2013 at 5:27 PM, Allen Wirfs-Brock
> <allen at wirfs-brock.com>  wrote:
>> We've previously concluded that RegExp.prototype.compile is part of web reality and should be included in the ES6 spec.  Whether it is put in the main spec. or in Annex B doesn't make a difference for the technical issue I'm about to discuss.
>>
>> Currently RegExp instances are specified to have four own data properties (source, global, ignoreCase, multiline) that are non-writable and non-configurable.
>>
>> This is fine because the standard spec. for RegExp initializes these properties when the object is constructed and according to the spec. they never change.
>>
>> However, RegExp.prototype.compile, as widely implemented in browsers allows the pattern and flags associated with an RegExp instance to be modified after object construction is completed and changing the pattern/flags also changes the values of these four properties.  Implementation just change their values even though the properties are non-writable/non-configurable.
>>
>> If we are going to include the compile method in the spec. we need to do so without violating the invariant that a non-configurable/non-writable property never changes its visible value.  There are several ways we might do this:
>>
>> 1) Change the specified attributes of these properties to {writable: false, configurable: true} or perhaps {writable: true, configurable: false}.  However, if we want to enforce that the only way to modify them was via the compile method we would have to make RegExp instances a special kind of exotic object in order to prevent assignment or Object.defineProperty from being used to modify the values of the property.
>>
>> Compatibility impact: change of property attribute from ES5
>> Spec/implementation impact: requires introduction of a new kind of exotic object
>>
>> 2) Change these properties to instance own accessor properties with a get function but no set function.  The accessors would produce values based upon the current pattern and flags.
>>
>> Compatibility impact:  visibly changes the properties from data properties to accessor properties.
>> Spec./implementation issues:  Do all instances share the same get functions or do 4 new  get function need to be created for every RegExp instance?  (Observable via get function identify)
>>
>> 3) Change these properties to prototype level accessor get-only accessor properties
>>
>> Compatibility impact: visible change from data to accessor property.  Inherited prototype property rather than instance property.  Inherited property could be over-ridden at instance level.
>>
>>
>> #3 is similar to how WebIDL now represents similar properties.  It is probably the easiest to spec. and implement.  It is the biggest change from a compat. perspective but I suspect that the actual compat. impact of any of these is small.  If I was designing RegExp from scratch and still had these requirements I would probably go with #3.
>>
>> What do people think?  #3 or #2?  I really don't want to go the exotic object route.
>>
>> Allen
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>


More information about the es-discuss mailing list