Re: Proxies fail comparison operator

2017-04-03 Thread Mark S. Miller
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

Re: Proxies fail comparison operator

2017-04-03 Thread Michał Wadas
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

Re: Proxies fail comparison operator

2017-04-02 Thread Alexander Jones
I would really hope that `===` can never be trapped. So much code would break! (Then again, I thought that about toString... :/) On Fri, 31 Mar 2017 at 15:21, Michael Lewis wrote: > Proxies do not reflect internal slots (Oriol) > > > You really don't *want* proxies to equal

Re: Proxies fail comparison operator

2017-03-31 Thread Michael Lewis
> > 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.

Re: Proxies fail comparison operator

2017-03-31 Thread Michael Kriegel
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

Re: Proxies fail comparison operator

2017-03-30 Thread Allen Wirfs-Brock
For background on design goals of ES proxies see https://research.google.com/pubs/archive/40736.pdf  On Mar 30, 2017, 12:44 PM, at 12:44 PM, Michael Lewis wrote: >> >> I don't believe Proxies are designed to give you any encapsulation to >a >> user who also has a reference to

Re: Proxies fail comparison operator

2017-03-30 Thread Alex Vincent
es7-membrane project: https://github.com/ajvincent/es7-membrane/ Alex From: Michael Lewis <m...@lew42.com> > To: es-discuss@mozilla.org > Cc: > Bcc: > Date: Thu, 30 Mar 2017 13:50:07 -0500 > Subject: Proxies fail comparison operator > Hello community, > > Th

Re: Proxies fail comparison operator

2017-03-30 Thread Oriol _
> Isn't the purpose of the proxy to be exchanged with the original, without any > negative side effects? This is not possible. Proxies do not reflect internal slots, so for example, in a browser, ```js var obj = document; var proxy = new Proxy(obj, {}); Node.prototype.contains.call(obj, obj);

Re: Proxies fail comparison operator

2017-03-30 Thread Michael Lewis
> > 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.

Re: Proxies fail comparison operator

2017-03-30 Thread Jordan Harband
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 wrote: > Hello

Proxies fail comparison operator

2017-03-30 Thread Michael Lewis
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