direct_proxies "problem"

Boris Zbarsky bzbarsky at
Wed Jan 9 11:57:52 PST 2013

On 1/9/13 2:45 PM, David Bruant wrote:
> Debattable. Here, there is no need to work with private state. The
> nodeType and tagName and parentNode (all public) are enough to do the
> matching I think.

No, because script can override them but matching needs to not depend on 
that, right?

> So the unknownPrivateSymbol trap wouldn't be called, but the get trap
> would.
> But the public properties could also be reflecting the state of private
> properties.

I'm confused again.  The "public" properties can do anything they want, 
since script can redefien them.

>> If so, what should it do if it throws?
> I guess swallow in that case. But maybe forward for qS/qSA... or swallow
> and consider the element as non-matching. I don't know what's the most
> useful.

What's most useful is not invoking any script at all for selector 
matching.  Note that the main consumer of selector matching is not 
qS/qSA but CSS rendering.

>> That wasn't my point.  My point was what happens to the tree traversal
>> the serialization algorithm does if the firstChild member (not the
>> getter, the actual internal state that stores the first child) is
>> defined to be a private symbol?
> oh ok, I'm not familiar with this algorithm. If the firstChild is a
> private symbol, then the unknownPrivateSymbol trap would be called. If
> the public firstChild is called, the get trap is.

What happens right now is that private state is consulted that cannot be 
changed by script directly and which can be accessed with no side-effects.

> Yes, depending on how they are defined, but pretty much anytime you
> touch a proxy, it calls a trap either the unknownPrivateSymbol or the
> get trap.

OK.  I doubt that's acceptable for internal algorithms like 
serialization, fwiw.

> Imagine a proxy for which the unknownPrivateSymbol and get traps would
> add a new element anywhere randomly to the DOM tree.

Yes, exactly.   Done that already.  ;)

> Now, the web platform defines a lot of other objects for which wrapping
> them with a proxy could make sense. I guess it would need to be on a
> case-by-case basis.

OK.  That might make sense; we'd have to look at specific cases.


More information about the es-discuss mailing list