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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >> >> >> _______________________________________________ >> es-discuss mailing >> [email protected]https://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 >> [email protected] https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing > [email protected]https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
