direct_proxies "problem"

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Jan 9 12:57:30 PST 2013


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 <
andrea.giammarchi at gmail.com> 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 <bzbarsky at 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 at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130109/cd568750/attachment-0001.html>


More information about the es-discuss mailing list