direct_proxies "problem"

David Bruant bruant.d at gmail.com
Wed Jan 9 11:45:08 PST 2013


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


More information about the es-discuss mailing list