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

[David Bruant]

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.
Excellent!

> 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.
Interesting.
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.

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