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.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
