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