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

[Tom Van Cutsem]

2013/2/20 Allen Wirfs-Brock <allen at wirfs-brock.com>

> Finally, I still think we should further consider the feasibly of a
> breaking change where
>      Object.preventExtensions(obj); for ( let k of
> Object.getOwnPropertyKeys(obj))
> Object.defineProperty(obj,k,{configurable:false});
> is no longer equivalent to
>       Object.freeze(obj)
> in terms of causing Object.isFrozen(obj) to return false.
>
> I think I previously asked if anybody is aware of situations where
> Object.isFrozen tests are done but Object.freeze is not used to set objects
> to the frozen state.  So far, no answers.  Anybody?
>

I did a little code search via GitHub on uses of Object.isFrozen in JS
code. The large majority seems to occur in test cases (incl. Test262) or
libraries involving ES5 shims for ES3. There's no doubt this breaking
change will get noticed, as Test262 contains code such as:

assertEq(Object.isFrozen(Object.preventExtensions({})), true);

However, here and there you can find some code that branches on frozenness,
although it's not always clear what the rationale behind it is, e.g.:
<
https://github.com/petekinnecom/portfolio_chaplin/blob/b241300968fe6011c54548f24e0c8cfcd5d6d663/app/views/tube_view.coffee#L39
>

That said, I don't think this is enough evidence either for or against the
breaking change.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130221/62c90b0e/attachment.html>