direct_proxies "problem"

David Bruant bruant.d at gmail.com
Wed Jan 9 14:19:26 PST 2013


Le 09/01/2013 21:30, Andrea Giammarchi a écrit :
> David ? You said: "It could still make sense to wrap a DOM Node with a 
> proxy to perform [[Get]] and [[Set]], etc. but definitely not put it 
> in the DOM tree."
>
> so this is the current scenario ... now, can you explain me a single 
> case where you would need that? If you can't use the DOM node then why 
> would create a proxy of one of them ?
If you wrap DOM Nodes in a proxy, you can do a membrane around them and 
make things like wrappedNode1.appendChild(wrappedNode2) work without 
needing shadow targets (just unwrapped in the traps, perform the native 
action and return a wrapped result)
It sounds like a worthwhile use case.

> I thought you agreed on the fact new Proxy() should throw instantly if 
> target cannot be proxified ...
For the short term I did (but now that the scope is reduced, I'm not 
sure). For the long term, I expected DOM objects could be proxified. 
Boris convinced me otherwise for DOM Nodes at least.

> in any case, here a counter example of what you guys are discussing:
> var
>    o = {},
>    p = new Proxy(o, {
>      get: function (target, name) {
>        console.log(name);
>        return target[name];
>      }
>    })
> ;
>
> p.test = 123;
> p.test; // log test
>
> o.test; // does nothing
> At this point would be more like deciding if DOM should threat internally the "o" or the "p"
> Having "special privileges" it could use o directly and pass back p when it comes to JS world.
> This will preserve performance. At the same time this will make the usage of proxies in the DOM
> world less useful because developers will be able to intercept only user defined interactions
> with these nodes but hey, it's already better than now where developers can create DOM proxies
> and use them only in RAM for who knows which reason 'cause in the DOM, where these identities
> belong, these fail.
I don't understand that part. Especially given that you're dealing with 
normal objects. What is it a counter-example of (we've been discussing 
about a lot of things)? How is it a counter-example?


> As summary, as it is now, this from Francois is my favorite outcome 
> from the discussion:
>
> I would certainly understand if the ECMAScript group settled up not to 
> work on Proxied native elements and specify that it should throw on 
> creation. However, I would advise to create an Object.hasIdentity(...) 
> method that returns true if the given object has a native identity
I missed that part. What's a "native identity"? a non-proxy object? It's 
been decided early that a Proxy.isProxy method should be avoided, 
because proxies should be indetectable from the objects they try to 
emulate from the ECMAScript perspective (internal 
[[Get]]/[[DefineOwnProperty]]/[[Keys]]...).
Boris has exposed a case (selector-matching) where the DOM API is 
complex enough that a proxy wrapping a DOM object could be discriminated 
against a native DOM object. This is a good trade-off I think. Allowing 
proxies to give the impression that the DOM object acts correctly from 
the ECMAScript internal properties perspective, but doesn't from the DOM 
perspective.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130109/341fcdb8/attachment.html>


More information about the es-discuss mailing list