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

André Bargull andre.bargull at udo.edu
Sun Mar 17 10:49:43 PDT 2013


The incompatibility you've noticed is just a spec bug in 
[[HasIntegrity]]. In step 2a of 8.3.3, the value of [[Extensible]] needs 
to be inverted. With that change applied, the code snippet will return 
`true`.

- André

> ------------------------------------------------------------------------
> 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  <https://mail.mozilla.org/listinfo/es-discuss>>
>
> >/  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/20130317/9c235afc/attachment-0001.html>


More information about the es-discuss mailing list