Proxies fail comparison operator

Mark S. Miller erights at google.com
Mon Apr 3 10:59:10 UTC 2017


The Left Hand of Equals
https://research.google.com/pubs/pub45576.html
is relevant to this discussion. The advice in this paper should be
considered new languages that are not yet committed to an equality
semantics. Frankly I have mixed feelings about it, but it is fascinating.

OTOH, for JavaScript, === must not trap.

Enjoy.



On Mon, Apr 3, 2017 at 2:07 AM, Michał Wadas <michalwadas at gmail.com> wrote:

> Proxies being able to intercept strict equality would be nightmare -
> WeakMap and WeakSet would need new semantics, potentially incompatible with
> previous one. Engines won't be able to optimize certain boolean expressions
> because of potential side effects.
>
> The only thing I can think of is not-a-trap:
>
> const foo = {};
> const bar = new Proxy({}, {
>     equals: foo
> });
> bar === foo; // true
> bar === {}; // false
>
> But even that can lead to many problems with design (how about new
> Proxy({}, {equals: bar})
>
>
> On 31/03/17 16:21, Michael Lewis wrote:
>
> 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
>
> _______________________________________________
> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170403/5942b228/attachment-0001.html>


More information about the es-discuss mailing list