RegExp.prototype.compile and RegExp instance properties

Mark S. Miller erights at google.com
Tue Jan 15 18:28:02 PST 2013


On Tue, Jan 15, 2013 at 6:21 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
>
> 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?

Yes. As far as I'm concerned, that is as good as #4. Thanks!

>  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
>>
>



--
    Cheers,
    --MarkM


More information about the es-discuss mailing list