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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
