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

Kevin Reid kpreid at
Wed Feb 20 12:08:02 PST 2013

On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall <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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list