My answer depends on a prior issue. Do we agree that in ES6,
RegExp.prototype is not itself a RegExp? 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
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
