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

Brendan Eich brendan at mozilla.com
Mon Jul 18 10:50:05 PDT 2011

On Jul 18, 2011, at 2:35 AM, David Bruant wrote:

> 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?

Good question. First impulse is to make that an error, but if proxies can be fixed, then the possibility of a fixed and inextensible proxy sufficing as return value of this hypothetical fix trap is plausible.

We would need continued, VM-level enforcement that such a fixed proxy cannot be extended, and of course that all of its properties are fixed.

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

The original proxy design had no support for fixed properties, so no way to let the handler intercede after fix without leaving too much bug/attack surface.

If we extend proxies to support fixed properties and ![[Extensible]], then we may be able to relax the design. But nothing here is truly arbitrary. It's a divide-and-conquer progression, I think.

Also, to repeat: implementation of becomes with a newborn is really quite slick and relatively easy to support, compared to more invasive fixed/inextensible enforcement.

> 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?

Because there was no way in sight to enforce the critical invariants. Possibly there is, now.

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

Yes indeed.


More information about the es-discuss mailing list