RegExp.prototype.compile and RegExp instance properties

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jan 15 18:21:08 PST 2013


On Jan 15, 2013, at 6:10 PM, Mark S. Miller wrote:

> Thanks. That's what I thought, but wanted to be sure.
> 
> In that case, I have no objections to any of these proposals, but I prefer #4.

I really think whenever possible we should be prefer designs that require or introduce new kinds of exotic objects.

However, I'd be happy to spec. RegExp compile such that it refuses to change any RegExp object that is non-extensible.  Would that make like easier for SES?  Again, it's unlike that this will actually break anything.

Given, that I'd still think #3 is the best choice.

Allen











> 
> On Tue, Jan 15, 2013 at 6:06 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> 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
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
>    Cheers,
>    --MarkM
> 



More information about the es-discuss mailing list