andrea.giammarchi at gmail.com
Wed Jan 9 07:22:52 PST 2013
only part I am "slightly skeptical" is that if developers cannot use
proxies with DOM nodes there's really not much to wait for ... they'll not
use them, end of the story.
If you mean "waiting for developers to complain same way I did" ... oh
well, I think is just a matter of time. I'll be here that day :D
Still, meanwhile, I would just change the current behavior throwing when
Proxy cannot work, i.e. with DOM ... or every library will have to
try/catch a generic appendChild in their code, as example, because of this
misleading possibility to wrap the DOM without the ability to retrieve back
the wrapped content.
On Wed, Jan 9, 2013 at 7:02 AM, Boris Zbarsky <bzbarsky at mozilla.com> wrote:
> 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 , 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<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  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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss