Last, but not least, even offline DOM proxies are pointless, here another
example without putting them in the DOM
var p = new Proxy(
document.createElement("p"),
{}
);
try {
p.appendChild(
document.createElement("span")
);
} catch(o_O) {
console.log(o_O.message);
}
try {
p.appendChild(
new Proxy(
document.createElement("span"),
{}
)
);
} catch(o_O) {
console.log(o_O.message);
}
So, as it is right now, there is not a single reason to make them
valid as new Proxy target, IMHO
br
On Wed, Jan 9, 2013 at 12:30 PM, Andrea Giammarchi <
[email protected]> wrote:
> 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 <[email protected]>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
>> [email protected]
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
