RegExp.prototype.compile and RegExp instance properties

Mark S. Miller erights at
Tue Jan 15 18:10:45 PST 2013

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.

On Tue, Jan 15, 2013 at 6:06 PM, Brendan Eich <brendan at> 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:
> (thread head)
> (my
> proposal)
> (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>  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


More information about the es-discuss mailing list