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

Tom Van Cutsem at
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).

- 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

- Object.freeze(proxy) and Object.isFrozen(proxy) must observably iterate
over all own properties of the proxy (same for seal/isSealed).


2013/3/18 Tom Van Cutsem < at>

> 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>
>> 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>
>>> 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: <>

More information about the es-discuss mailing list