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.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
