get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
bruant.d at gmail.com
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 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss