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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
