get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Tom Van Cutsem tomvc.be at gmail.com
Mon Mar 18 12:33:16 PDT 2013


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.be at 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 <allen at 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 <brendan at 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
>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130318/1258f87c/attachment.html>


More information about the es-discuss mailing list