Proxies fail comparison operator
Michał Wadas
michalwadas at gmail.com
Mon Apr 3 09:07:59 UTC 2017
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
> <mailto: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
>> <mailto: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 <mailto: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 <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>> <https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>> <https://mail.mozilla.org/listinfo/es-discuss>
>
> --
> Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com <http://www.actifsource.com> • +41 56 250 40 02 <tel:+41%2056%20250%2040%2002>
>
> _______________________________________________ es-discuss mailing
> list es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
> _______________________________________________
> 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/20170403/ba5c45e2/attachment-0001.html>
More information about the es-discuss
mailing list