Le 09/01/2013 19:43, Boris Zbarsky a écrit :
On 1/9/13 1:23 PM, David Bruant wrote:
What happens if unknownPrivateSymbol throws?
I'm not sure yet. My guess is that the error should be propagated
So just to make sure we're on the same page here... Say I have a
proxy for a <div> and I put it in the DOM. Say my page has:
<style>
section > div { color: green; }
</style>
Should matching that selector against the div call
unknownPrivateSymbol when getting the parent of the div?
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.
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.
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.
Note, by the way, that UAs are working on doing off-main-thread
selector matching and that the exact timing/ordering of selector
matching is not defined and won't be (because it's a state thing, not
a procedural algorithm), so doing anything script-observable anywhere
here is pretty weird.
Agreed. Maybe this point settles the argument. That's what I was
referring to when I was talking about "exposing guts" of DOM objects.
The downside is that it forces to define a lot of things as algorithms
at the expense of optimizations like the one you describe.
If the serialization algorithm is represented as a private symbol'ed
methods on objects, then, doing a [[Get]] with this symbol as argument
would call the unknownPrivateSymbol trap. The result of this trap (throw
or return (return value is ignored)) determines whether the algorithm is
actually called.
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.
unknownPrivateSymbol is a trap, so I'm not sure I understand your
question.
My question boils down to this: are we talking about introducing
things that would be able to modify a DOM tree while it's being
iterated by internal browser algorithms? Because doing that is not
acceptable.
It sounds like so far the answer is "maybe, depending on how those
traversals are defined in the specs"
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.
Imagine a proxy for which the unknownPrivateSymbol and get traps would
add a new element anywhere randomly to the DOM tree.
I agree it'd be attrocious!
You've convinced me against proxies for DOM Nodes.
It could still make sense to wrap a DOM Node with a proxy to perform
[[Get]] and [[Set]], etc. but definitely not put it in the DOM tree.
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.
It can have side-effects, the only important case is whether a public
method call result in 0 or 1+ calls on a given object.
Uh... no. How can that be the only important case???
What I meant
above (but didn't say) is that whether it's called (0 or 1) is
important, but if it's 1 or 5 times for a given public method call, it
doesn't matter much.
For a function with side-effects this seems blatantly false to me, so
I must be missing something. What am I mising?
I hadn't thought of cases like selector matching. I was thinking of
function calls like appendChild that could be considered as "atomic" you
call it once and whatever happens in the middle (the number of trap
calls), in the end, the operation happened or not and trap call
side-effects probably don't affect the appendChild algorithm. It
actually depends on how it's exactly specified.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
