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

Allen Wirfs-Brock allen at
Sun Mar 17 11:16:19 PDT 2013

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.


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