RegExp.prototype.compile and RegExp instance properties

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jan 15 17:27:31 PST 2013


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





More information about the es-discuss mailing list