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

[David Bruant]

Le 20/02/2013 21:08, Kevin Reid a écrit :
> On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall <nathan.wall at live.com 
> <mailto:nathan.wall at live.com>> wrote:
>
>     `Object.isFrozen` and `Object.isSealed` don't really seem that
>     helpful to me for the very reasons you've discussed: They don't
>     represent any real object state, so they don't accurately tell me
>     what can be done with an object.  If I could I would argue in
>     favor of their removal, though I know it's too late for that.
>
>     I would be curious to see legitimate uses of `isFrozen` and
>     `isSealed` in existing code if anyone has anything to offer.
>
>
> I just took a look at uses of Object.isFrozen in Caja and I find that 
> all but one are either in tests (test that something is frozen) or in 
> sanity checks (if this isn't frozen, do not proceed further, or freeze 
> it and warn).
>
> The remaining one is in a WeakMap abstraction used for trademarking: 
> an object cannot be given a trademark after it is frozen. (The 
> rationale here, while not written down, I assume is that a defensive 
> object's "interface" should not change, and it is an implementation 
> detail that this particular information is not stored in the object.) 
> There is a comment there suggesting we might strengthen this check to 
> only permitting _extensible_ objects to be marked.
And in an ES6 world, you'll probably use an actual WeakMap anyway?

Thanks for sharing this experience from Caja,

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130220/e854c072/attachment.html>