David ? You said: "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."
so this is the current scenario ... now, can you explain me a single case
where you would need that? If you can't use the DOM node then why would
create a proxy of one of them ? I thought you agreed on the fact new
Proxy() should throw instantly if target cannot be proxified ... in any
case, here a counter example of what you guys are discussing:
var
o = {},
p = new Proxy(o, {
get: function (target, name) {
console.log(name);
return target[name];
}
})
;
p.test = 123;
p.test; // log test
o.test; // does nothing
At this point would be more like deciding if DOM should threat
internally the "o" or the "p"
Having "special privileges" it could use o directly and pass back p
when it comes to JS world. This will preserve performance. At the same
time this will make the usage of proxies in the DOM world less useful
because developers will be able to intercept only user defined
interactions with these nodes but hey, it's already better than now
where developers can create DOM proxies and use them only in RAM for
who knows which reason 'cause in the DOM, where these identities
belong, these fail.
As summary, as it is now, this from Francois is my favorite outcome from
the discussion:
I would certainly understand if the ECMAScript group settled up not to work
on Proxied native elements and specify that it should throw on creation.
However, I would advise to create an Object.hasIdentity(...) method that
returns true if the given object has a native identity
br
On Wed, Jan 9, 2013 at 11:57 AM, Boris Zbarsky <bzbar...@mozilla.com> wrote:
> 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
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
