On Tue, Jan 15, 2013 at 6:21 PM, Allen Wirfs-Brock <[email protected]> wrote: > > On Jan 15, 2013, at 6:10 PM, Mark S. Miller wrote: > >> 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. > > I really think whenever possible we should be prefer designs that require or > introduce new kinds of exotic objects. > > However, I'd be happy to spec. RegExp compile such that it refuses to change > any RegExp object that is non-extensible. Would that make like easier for > SES?
Yes. As far as I'm concerned, that is as good as #4. Thanks! > Again, it's unlike that this will actually break anything. > > Given, that I'd still think #3 is the best choice. > > Allen > > > > > > > > > > > >> >> 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 >> > -- Cheers, --MarkM _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
