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

David Bruant bruant.d at
Wed Feb 20 12:15:06 PST 2013

Le 20/02/2013 21:08, Kevin Reid a écrit :
> On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall <nathan.wall at 
> <mailto:nathan.wall at>> 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,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list