On 1/9/13 5:24 AM, David Bruant wrote:
When later getting that node out of the DOM with .firstChild, what
should be handed back? The proxy that was passed in, the JS object
that proxy was wrapping, something else (e.g. an exception is thrown)?
The principle of least surprise would say the proxy that was passed in
That's actually not that great either. If you're handing out proxies as
membranes, and the caller of .firstChild should be getting a different
membrane than the caller of appendChild had, you lose.
Also if you wrap untrusted code in a membrane [1], you don't want this
untrusted code to be handed the actual target, but the wrapped object
(so the proxy).
If you want membranes you have to be able to pick the right membrane
when handing out the object from any WebIDL method/getter, basically.
Proxies expose the guts of algorithms applied on objects (exact sequence
of internal methods with arguments).
Yes, true, for purposes of ES stuff.
it would be equally true for browser objects
I'm not quite sure what this part means.
Since these guts aren't specified in ECMAScript semantics
Again, not sure what that means.
The way the DOM works in practice right now, if one were to implement it
in ES, is that each script-exposed object is just a normal ES object
with some getters/setters/methods on its proto chain. There is also a
bunch of state that's not stored in the objects themselves, and a Map or
WeakMap from the objects to their state, depending on the
implementation; the GC issues are a bit complicated. The
getters/setters/methods work on this out-of-band state, for the most
part (there are some exceptions; e.g.
http://dev.w3.org/2006/webapi/WebIDL/#dfn-attribute-setter for the
[PutForwards] case, though that may not match UA behavior well enough;
we'll see).
So in this view, passing in a proxy should not work, because it can't be
used to look up the out-of-band state.
Now if you happen to have access to engine-level APIs you can unwrap the
proxy and use the target to index into the Map... but at that point I
agree that you've left ES semantics land.
Now maybe you're arguing that the above model is wrong and there should
be some other model here. I welcome you describing what that model is.
But the above model, I believe, is fully describable in ES semantics
(and in fact dom.js does exist).
I agree with Andreas about the convenience for web developers [2] but I
doubt it would be practical to have it in the short term both because of
under-specification and implementation complexity.
Agreed, at this point.
Let's wait for a combinaison of 1) authors using proxies, 2)
implementors move forward on WebIDL compliance
Of course the more investors invest in a rewrite of their DOM stuff, the
less likely they are to want to change it.
So if we think we should be changing things somehow in the future, and
have a good idea of what those changes will look like, the better it is
to lay the groundwork now. Rewriting the binding layer for a browser is
a pretty massive project, and there's a limit to how often UAs want to
do it. ;)
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
