direct_proxies "problem"

Boris Zbarsky bzbarsky at mozilla.com
Wed Jan 9 09:26:40 PST 2013


On 1/9/13 12:13 PM, David Bruant wrote:
> There is some data associated with the object. Whether it's a (private)
> property or a map entry is an implementation detail
...
> Choosing symbols or a weakmap would make a huge difference in how proxy
> replacement would react to DOM algorithms.

Then it's not an implementation detail, now is it?  I'm having a hard 
time understanding how you can reconcile those two sentences.

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

I'm not sure I see how yet, but I'm not as familiar with proxies as you 
are.  I assume the link above was actually [1]?  I'm having a hard time 
making sense of it, largely due to missing context, I think.

What happens if unknownPrivateSymbol throws?  Would internal DOM 
algorithms like the serialization algorithm invoke unknownPrivateSymbol? 
  If so, would unknownPrivateSymbol be allowed to modify the DOM tree?

> That would be representing private state with private symbols properties.

OK, see above.

> Dom.js started and is developed in a world where no engines has
> implemented symbols.

It started in a world with no WeakMap or Map either.

> 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 believe it adds those on the target object but the thing it hands out 
to script is actually a proxy for that object.

I'm not sure how it handles "expando" property sets that collide with 
its _properties, though.  But again, it was developed in a world without 
WeakMap/Map.

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

Indeed.

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

Whether it's a big deal depends on when it's called and what it can do. 
  If it can have side-effects, non-interop in how many times it's called 
is a big deal to me.

-Boris


More information about the es-discuss mailing list