A DOM use case that can't be emulated with direct proxies

Tom Van Cutsem tomvc.be at gmail.com
Tue Dec 18 13:36:33 PST 2012

2012/12/13 David Bruant <bruant.d at gmail.com>

>  Le 13/12/2012 20:47, Jason Orendorff a écrit :
> David: https://gist.github.com/4279162
> I think this is what Kevin has in mind. Note in particular that the target
> of the Proxy is just a dummy object, and the handler ignores it entirely.
> The proxy uses it for invariant checks, but the intent is that those would
> always pass.
> but they do not; try:
>     var [p, setTarget] = retargetableProxy({}); // I love destructuring
> sooo much!
>     Object.defineProperty(p, 'a', {configurable: false, value:31});
>     setTarget({});
>     Object.getOwnPropertyDescriptor(p, 'a'); // invariant check throws here
> Any variant that can be written will have the same issue. Even trickeries
> with the defineProperty trap.
> The proxy is enforcing invariants against the dummy [[target]]. The same
> is to be expected from WindowProxy instances even if their underlying
> window changes. It doesn't matter if the invariant is enforced on the dummy
> target on an actual window instance. It is enforced and that's the
> "problem" (with WindowProxy implemented as they are now not being emulable
> with proxies)

To clarify, there won't be any invariant violations if you ensure all three
of the following conditions hold:

a) the dummy target object never acquires any invariants (letting it be a
dummy empty object and otherwise ignoring the target completely achieves

b) handler traps that *query* the proxy never reveal any invariants, even
if the "real" target currently pointed-to has invariants (i.e.
getOwnPropertyDescriptor always changes the returned property descriptor's
configurable attribute to true, isExtensible always returns false, etc.)

c) handler traps that *update* the proxy refuse to commit
(preventExtensions throws, defineProperty returns false when dealing with
configurable:false properties, ...)

It's a heavyweight way of going about things, but as Brandon mentioned,
it's the price to pay for wanting to do weird things no normal ES5 object
could ever do. The more a proxy's behavior deviates from that of an ES5
object, the uglier its implementation will be to "circumvent" the invariant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121218/19ae1e17/attachment-0001.html>

More information about the es-discuss mailing list