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