ooops, that's a typo, the toString is HTMLParagraphElement or the correct one.
The problem I have here is with identity indeed where this is "same as target" in JS world and "something else" behind the scene in C++ world ... this is bad because we cannot recognize proxies and we cannot then avoid Errors or problems with automated code. We think is a DOM node, everything tell us is a DOM node, when we use it everything breaks? this is going nowhere ... I'd rather prefer errors during initialization if the target object cannot be shadowed by the proxy, no matter if real ECMA or fake ECMA :D br On Tue, Jan 8, 2013 at 1:46 PM, David Bruant <[email protected]> wrote: > Le 08/01/2013 21:40, Andrea Giammarchi a écrit : > > So, I am playing with FF 18 and I have this behavior: >> var a = new Proxy([], {}); >> console.log(a instanceof Array); // true >> console.log(Array.isArray(a)); // true >> console.log({}.toString.call(**a));// [object Array] >> >> Function.apply(null, a); // anonymous() >> Cool uh? there's no way to tell that a is not actually an array but >> rather a proxy: awesome!!! >> Now I go in that dark place called DOM: >> var n = new Proxy(document.createElement("**p"), {}); >> console.log(n instanceof HTMLElement);// true >> console.log({}.toString.call(**n)); // true >> > really, "true" for toString? > > document.body.appendChild(n); >> // Error: Could not convert JavaScript argument arg 0 >> [nsIDOMHTMLBodyElement.**appendChild] >> >> Is this meant? 'cause it looks lik ewe have half power here and once again >> inconsistencies ... thanks for explaining me this. >> > I don't remember when, but we had brief an exchange about it with Tom on > es-discuss. I'm in favor for direct proxies to work as replacement of > browser objects when they wrap it (Tom was against IIRC, but i can't > remember the reason). It wasn't conceivable in the previous design, but the > direct proxy design technically allow it. > > Reading bugmail, following how implementations support WebIDL (bridge > between ECMAScript and browser objects), I doubt it would be possible to > see that happening in the short term. For this to happen would require a > huge amount of spec work (define every single web spec algorithm in terms > of ECMAScript object internal operations) and implementation obviously as > Tab explained. > > > One idea would be in the short term that implementations reliably *always* > throw when trying to wrap non-ECMAScript objects and play with them as if > they were legit browser objects. If the need becomes strong, implementation > can later allow it (turning an error into a legit thing is usually not web > breaking) > > David >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
