Allen and I had a conversation that clarified things.
Essentially, the plan is to only have
[[PreventExtensions]]/[[IsExtensible]] internal MOP methods, and to only
have the corresponding preventExtensions/isExtensible traps for proxies.
Proxies won't have isSealed, isFrozen, seal and frozen traps and there will
be no corresponding Reflect.{isSealed,isFrozen,seal,frozen} methods.
Calling Object.freeze(proxy) instead triggers the proxy's
getOwnPropertyNames trap and then updates each own property of the proxy
via defineProperty. Similar story for Object.isFrozen(proxy).
Pro:
- We get rid of 4 MOP methods
([[Freeze]],[[Seal]],[[IsFrozen]],[[IsSealed]]). This simplifies both the
internal MOP and the Proxy API.
- Freezing and sealing always behave consistently, even in the face of
proxies. There's no chance for a proxy to implement multiple traps
inconsistently.
Con:
- Object.freeze(proxy) and Object.isFrozen(proxy) must observably iterate
over all own properties of the proxy (same for seal/isSealed).
Cheers,
Tom
2013/3/18 Tom Van Cutsem <tomvc...@gmail.com>
> Ok, somehow I had completely missed "9.3.10 TestIntegrityLevel (O, level)"
> which does exactly the derived computation for sealed and frozen objects.
>
> I think André is right though about the bug in 8.3.3 step 2.a.
>
> Cheers,
> Tom
>
>
> 2013/3/17 Allen Wirfs-Brock <al...@wirfs-brock.com>
>
>> Tom recently suggested that that we really don't need MOP-level or trap
>> operations from freezing, sealing and testing those states. Also, there
>> seems to be minimal support for having explicit freeze/sealed integrity
>> states or for adding integrity integrity states. So I'm probably going to
>> go make to an style design. We'll only have [[IsExtensible]] and
>> [[PreventExtensions]] MOP/trap/Reflect operations.
>> Object.freeze/seal/isFrozen/isSealed will be derived operations.
>>
>> Allen
>>
>>
>>
>> On Mar 17, 2013, at 10:16 AM, Tom Van Cutsem wrote:
>>
>> Hi,
>>
>> Allen's latest draft (Rev. 14) contains the change where
>> [[Freeze]],[[Seal]] and [[PreventExtensions]] have been consolidated into
>> [[HasIntegrity]]/[[SetIntegrity]]. While no changes were made to the Proxy
>> API (i.e. no has/getIntegrity traps yet), the definition of
>> Object.{freeze,seal,preventExtensions} did change, and this is sufficient
>> to expose an incompatibility with ES5, namely:
>>
>> Object.isFrozen(Object.preventExtensions({})) // true in ES5, false in
>> ES6 Rev14 draft
>>
>> I still feel like the consolidation isn't worth this incompatibility.
>>
>> Allen, could you clarify what your intent is? Is it your intent that
>> this incompatibility will be fixed with further spec changes?
>>
>> Cheers,
>> Tom
>>
>> 2013/2/21 Brendan Eich <bren...@mozilla.com>
>>
>>> Tom Van Cutsem wrote:
>>>
>>>> That said, I don't think this is enough evidence either for or against
>>>> the breaking change.
>>>>
>>>
>>> I have a hard time believing we can break ES5. It has been shipping for
>>> years (plural, at least in one case) in major browsers that evergreen their
>>> user bases.
>>>
>>> /be
>>>
>>
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
