Le 09/01/2013 16:02, Boris Zbarsky a écrit :
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.
I went out of my way merging 2 incompatible use cases (put a wrapped
node in a document and membrane for which the document would be wrapped
in the same membrane). Sorry about that.
I still think the object that was introduced is the one that should be
handed back. If you give access to some code to a membraned version of
the DOM tree, you know whenever they want a given node and can pick the
correct membraned node instead (a weakmap can do this job really well.)
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
or private symbols (used to be called "private names")
from the objects to their state, depending on the implementation
There is some data associated with the object. Whether it's a (private)
property or a map entry is an implementation detail; my point is that
you can't state "a bunch of state that's not stored in the objects
themselves". properties or the [[Extensible]] boolean could also not be
stored in the objects themselves, that's an implementation concern.
Choosing symbols or a weakmap would make a huge difference in how proxy
replacement would react to DOM algorithms.
If the DOM in terms of accessing private properties, then proxies can
replace DOM objects transparently. Their "unknownPrivateSymbol" trap
will be called [2] and if they don't throw, the access to the private
property will be transparently forwarded to the target without the
private symbol ever leaking (it actually wouldn't need to exist in
implementations).
That actually could work...
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.
I agree with this analysis.
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.
That would be representing private state with private symbols properties.
But the above model, I believe, is fully describable in ES semantics
I think so too.
(and in fact dom.js does exist).
Dom.js started and is developed in a world where no engines has
implemented symbols.
Also, last I checked it adds non-standard convieniences [2] and
_properties for "private" state [3][4]. Am I looking at the wrong version?
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. ;)
I hear you :-)
Yet, assuming the private symbol idea would be the way to go, there is
still a need for specs to define private state in terms of private
symbols before implementations can start, no? I guess, worst case
scenario, with a lack of spec, implementations would be
non-interoperable only in how many times the unknownPrivateSymbol trap
is called which I don't think is really a big deal.
I feel I may have been too quick in my explanation. If I have, don't
hesitate to ask questions or ask me to resolve a problem or your choice.
David
[1] http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names
[2] https://github.com/andreasgal/dom.js/blob/master/src/impl/Node.js#L249
[3] https://github.com/andreasgal/dom.js/blob/master/src/impl/Node.js#L411
[4] https://github.com/andreasgal/dom.js/blob/master/src/impl/Node.js#L422
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
