direct_proxies "problem"

Alex Russell slightlyoff at google.com
Wed Jan 9 07:54:21 PST 2013


On Tuesday, January 8, 2013, Tab Atkins Jr. wrote:

> On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com <javascript:;>> wrote:
> > 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
> > 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.
>
> As Francois points out, this is a known problem.  DOM objects don't
> live solely in JS - they tend to have C++ backing classes that do a
> lot of the heavy lifting.  Your average JS object, without such C++
> support, simply won't work with the JS methods that, when they call
> back into C++, expect to see the DOM C++ classes.
>
> This is a problem elsewhere, too - Web Components really wants to make
> it easy to subclass DOM objects, but we've had to twist ourselves into
> knots to do it in a way that alerts the C++ side "early enough" that
> it can create the new objects with appropriate backing C++ classes.
>
> It can potentially be solved by efforts like moving the DOM into JS,
> which browsers are pursuing to various degrees, but it's a hard
> problem on the impl side.  Meanwhile, there is unforgeable magic
> behind DOM objects, and nothing we can really do about it.
>

Well, we can attempt (as much as is practicable at any point) to avoid
"blessing" this split and the crazy behaviors it begets. Designing for
DOM-in-JS world is the only way to stay sane. What JS-in-DOM can't do that
DOM needs, we should add. But not much more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130109/11f738ae/attachment-0001.html>


More information about the es-discuss mailing list