Proxies fail comparison operator

Michael Lewis mike at lew42.com
Fri Mar 31 14:21:26 UTC 2017


>
> Proxies do not reflect internal slots (Oriol)


 You really don't *want* proxies to equal their underlying objects:
> proxies can show properties that the underlying object doesn't have, hide
> properties that the underlying object does have, alter the appearance of
> other proxies, etc.  (Alex Vincent)


What you really want to ask for is for JavaScript support for overriding
> the comparison operator for a class. (and other operators, too...)
>  (Michael Kriegel)



Sounds like the purpose of Proxies evades me and unfortunately, I don't
have time to read up on it, but thanks for the link, Allen.  Any article
that begins with the word *abstract* scares me.

Yes, Michael, I think *operator traps* for the proxies would be a perfect
solution.  Then I could let my proxies === my targets, woohoo!

Thanks everyone, great feedback.




On Fri, Mar 31, 2017 at 5:06 AM, Michael Kriegel <
michael.kriegel at actifsource.com> wrote:

> I agree with everyone, that the proxy object should not equal the proxied
> object.
>
> What you really want to ask for is for JavaScript support for overriding
> the comparison operator for a class. (and other operators, too...)
>
> On 30.03.2017 21:44, Michael Lewis wrote:
>
> I don't believe Proxies are designed to give you any encapsulation to a
>> user who also has a reference to the target object
>>
>
> So the Proxy wasn't designed to proxy real objects that operate with real
> code?
>
> `myRealFunction(obj)` <---> `myRealFunction(proxy)`
>
> This could be incredibly useful.  You could log every get/set/method call
> on the obj.  And, this *will* work in 99% of use cases.  Just cross your
> fingers that your code doesn't use the comparison operator.
>
> you'd have to never provide the reference to the target object in the
>> first place.
>
>
> Yea, that's what I'm doing.  But inside a constructor, you basically have
> to create the proxy first thing, call all initialization logic on the proxy
> instead of `this`, and return the proxy.  And when you're only proxying if
> `log: true` has been set, you have to maybe proxy, but maybe not.  I can
> work around it, but I'm not happy about it ;)
>
> ljharb ftw!  (I am delevoper on IRC, the one frequently ranting about the
> software revolution)
>
> On Thu, Mar 30, 2017 at 1:53 PM, Jordan Harband <ljharb at gmail.com> wrote:
>
>> I don't believe Proxies are designed to give you any encapsulation to a
>> user who also has a reference to the target object - you'd have to never
>> provide the reference to the target object in the first place.
>>
>> On Thu, Mar 30, 2017 at 11:50 AM, Michael Lewis <mike at lew42.com> wrote:
>>
>>> Hello community,
>>>
>>> The proxy is almost an identical to the underlying object, but it* fails
>>> a comparison check with the underlying object.*
>>>
>>> This means that if anyone gets a reference to the underlying object
>>> before it is proxied, then we have a problem.  For example:
>>>
>>> var obj = {};
>>> var proxy = new Proxy(obj, {});
>>> obj == proxy; // false
>>>
>>> *Isn't the purpose of the proxy to be exchanged with the original**,
>>> without any negative side effects?  *Maybe that's not the intended use
>>> case, but it's a useful one.  And, besides the comparison, I can't think of
>>> any other "negative side effects".
>>>
>>> It seems like the Proxy could have a *comparison trap*.  The comparison
>>> could pass by default, and you could use the trap if you wanted to make
>>> `proxy == obj` fail.
>>>
>>> Also, a slight tangent: it would be awesome if you could *skip
>>> debugging proxy traps when stepping through code.  *When you proxy both
>>> `get` and `apply` for all objects/methods, you have 10x the work when
>>> trying to step through your code.
>>>
>>> I just subscribed to this list.  Is this an appropriate venue for this
>>> type of inquiry?  I appreciate any feedback.
>>>
>>>
>>>
>>> Thanks!
>>>
>>> Michael
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
>
> _______________________________________________
> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
> --
> Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02 <+41%2056%20250%2040%2002>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170331/958c5383/attachment.html>


More information about the es-discuss mailing list