did you read anything I have been written in this thread or you have a short memory ?
I am strongly recommending to throw an error the moment an object cannot be proxied . I don't want to detect node and proxied node, I don't want DOM node to be allowed to be the first argument of the Proxy. I don't want create 50 line sof code that demonstrates isDOMProxy is possible because you all know it is right now so, I am just waiting for the verdict about this **issue** because if this is meant ant won't change, the fact we can do new Proxy(HTMLElement), I want write about this **problem** and inform developers and library authors we gonna have bad time if a proxy leaks anywhere in a program. thanks for any outcome br On Sat, Jan 12, 2013 at 1:40 PM, David Bruant <[email protected]> wrote: > Le 12/01/2013 21:58, Andrea Giammarchi a écrit : > > that is a (quick/imperfect/asexample) way to detect a proxy while I > understand these should not be detectable. > > {} and [] also return true to your test, but they're not proxies. You > cannot use an imperfect test to prove a point. > As I (and others now) said, the DOM, in order to be self-consistent (and > have performance in operations like selector matching) can only use objects > it created through HTML parsing or methods like document.createElement. It > will refuse any other object, proxy or not. With tree manipulation methods > (like appendChild), the only relevant test you can be making is "is this > object a DOM created genuine node?". This rules out *any* object. This > includes proxies to node > > > Consider that as conditional check after node instanceof Element in > order to know if that node is usable or not as DOM element. > > Object.create(Element.prototype)? > > > There, a way to simulate an isProxy method and it does not matter if > that's silly ... is possible > > The possibility to use proxies in the DOM tree was ruled out because of > the selector matching use case. If you have a solution to put proxies in > the DOM tree without ruining selector matching perf, you will be listened. > > David > > > > > On Sat, Jan 12, 2013 at 11:24 AM, Brendan Eich <[email protected]>wrote: > >> This is silly. >> >> I can use the closure pattern to vend objects that do not satisfy the >> internal constraints the DOM imposes on some of its objects. No proxies in >> sight. >> >> So why is the method you wrote named "isDOMProxy" and whatever in the >> world does it have to do with Proxy? >> >> /be >> >> Andrea Giammarchi wrote: >> >>> and in both cases you would have ... >>> >>> Proxy.isDOMProxy = function (node) { >>> try { >>> document.documentElement.appendChild(node); >>> document.documentElement.removeChild(node); >>> return false; >>> } catch(gotcha) { >>> return true; >>> } >>> }; >>> >>> that's why I have talked about inconsistencies all over at the very >>> beginning of this thread :) >>> >>> br >>> >>> >>> >>> >>> >>> >>> On Sat, Jan 12, 2013 at 10:26 AM, Nathan Wall >>> <[email protected]<mailto: >>> [email protected]>> wrote: >>> >>> Nathan wrote: >>> > >>> > Hey Tom, I think you missed my point. The point was that in >>> David and Boris' discussion they agreed that the DOM should throw >>> if it is given a Proxy in `appendChild`. That sounded to me like >>> it presumed that the DOM had a magical ability to distinguish >>> between DOM objects and their proxies. That seemed to contradict >>> the point David made that Proxies should not be distinguishable >>> from their targets (e.g. the no `Proxy.isProxy` decision). If real >>> DOM had a way to determine if something was a proxy (with a target >>> of a *real* DOM node) and throw but there was no way for an >>> emulated DOM (in a non-DOM environment) to determine if an object >>> was a proxy with a target to an emulated DOM node or just a plain >>> emulated DOM node, then the DOM has magical abilities that the >>> emulated DOM can't have. That was my concern. >>> > >>> > David's reply works, though, I think. He stated that since you >>> have to create DOM nodes using a method of the DOM itself >>> (`document.createElement`, `document.createTextNode`), then >>> emulated DOM could track all objects created and compare them >>> against objects passed into `appendChild`, and since a proxy would >>> have a different object identity from its target, the emulated DOM >>> would have a way to distinguish proxies from their targets. >>> > >>> > Nathan >>> >>> >>> In short, if real DOM can throw when given a proxy of a real DOM >>> node, fake DOM should also be able to throw when given a proxy of >>> a fake DOM node. >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] <mailto:[email protected]> >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >>> > > > _______________________________________________ > es-discuss mailing [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
