A DOM use case that can't be emulated with direct proxies
Tom Van Cutsem
tomvc.be at gmail.com
Tue Dec 18 13:37:32 PST 2012
2012/12/13 Kevin Reid <kpreid at google.com>
> Yes, exactly. I was just this minute in the process of writing such a
> proxy myself, and have not yet confirmed whether it is accepted by the
> invariant checks for all the cases I'm thinking of (testing against FF
> Note that either
> (1) all the switched-among targets need to have the same [[Prototype]],
> (2) the proxy has to pretend that all inherited properties are actually
> (3) or mutating [[Prototype]] (i.e. __proto__) needs to be possible.
> In my particular use case, (1) is not a suitable option, so I would
> implement (2) if (3) is not available. Not that I approve of (3), but one
> does what one must to accomplish virtualization.
It's worth noting that direct proxies do not enforce any invariants w.r.t.
inherited property access/update. For instance, the "get" trap is allowed
to return arbitrary values over time for a non-configurable, non-writable
In other words, it's as if direct proxies always have a mutable __proto__
(even if Object.getPrototypeOf returns a stable result). Hence, (3) is the
best way to rationalize the behavior of direct proxies.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss