[[Extensible]]and Proxies (Was: Proxy.isProxy )

David Bruant david.bruant at labri.fr
Mon Jul 18 02:35:22 PDT 2011

Le 18/07/2011 03:03, Brendan Eich a écrit :
> On Jul 17, 2011, at 6:01 PM, Brendan Eich wrote:
>> See my previous reply, about fixed properties, the fix trap, controlling the [[Class]] of the object the proxy "becomes" upon fixing, and preserving the (preventExtensions, seal, freeze) distinction when fixing.
> Here's a possibly dumb question: why not have fix return not a pdmap for the new Object instance to be fixed at those properties, rather an object (of any class) to be fixed by the exact cause of the fix trap: preventExtensions, seal, or freeze?
Interesting. What would happen if the returned object is a proxy?

Regardless, my understanding of the fix+become design was to enforce the 
non-extensibility invariants (and if I'm missing something, please tell 
me so). I have to admit that it really feels weird to me that because I 
call Object.{preventExtensions|seal|freeze}, my handler should stop its 
existence and my proxy should "become" another object (even a native 
array or a DOM Node if we want to allow that). It sounds very arbitrary 
to me. Why does preventing extension should throw my loggers away? Or 
stop the forwarding of all operations to the target object if I defined 
a forwarder?
Actually, I've raised the issue in another thread that a forwarder proxy 
cannot properly forward Object.{preventExtensions|seal|freeze} to the 
target object because within the fix trap, there is no way to 
distinguish between the 3.


More information about the es-discuss mailing list