A case for removing the seal/freeze/isSealed/isFrozen traps

David Bruant bruant.d at gmail.com
Wed Feb 13 11:53:27 PST 2013

Le 13/02/2013 20:36, Tom Van Cutsem a écrit :
> Hi David,
>     I went a bit too far suggesting frozen objects could de-facto
>     disappear with proxies.
>     I'm still unclear on the need for specific
>     seal/freeze/isSealed/isFrozen traps
> I think Allen and I reached consensus that we might do without those 
> traps.

> In addition, Allen was considering an alternative design where the 
> "state" of an object (i.e. "extensible", "non-extensible", "sealed" or 
> "frozen") is represented explicitly as an internal property, so that 
> Object.isFrozen and Object.isSealed must not "derive" the state of an 
> object from its properties.
So what would happen when calling Object.isFrozen on a proxy? Would 
Object.isFrozen/isSealed/isExtensible reach out directly to the target? 
or a unique "state" trap returning a string for all of them? ("state" is 
too generic of a name, but you get the idea)

Regardless on the final decision on (full) notification proxies, maybe 
these operations (isSealed/isFrozen) could have notification trap. The 
invariant is that the answer has to be the target one (all the time), so 
the trap return value is irrelevant. Like the getPrototypeOf trap.

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

More information about the es-discuss mailing list