direct_proxies "problem"

David Bruant bruant.d at
Wed Jan 9 09:13:49 PST 2013

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 

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. 
> 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.



More information about the es-discuss mailing list