Proxies fail comparison operator

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proxies fail comparison operator

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 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

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.  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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

Oriol _
In reply to this post by Michael Lewis
> 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); // true
Node.prototype.contains.call(proxy, proxy); // TypeError: 'contains' called on an object that does not implement interface Node.
```

So it would be bad if `obj === proxy` returned true but the values had different behaviors. I think `+0 === -0` despite `1/+0 !== 1/-0` is already enough of a nightmare.

--Oriol

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

Alex Vincent
In reply to this post by Michael Lewis
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.

What you probably want is to never deal with the underlying object in the first place, unless you absolutely have to.  That's why you'd create a proxy anyway...

Have you heard about membranes?  I've talked about them on this list recently, as have several others over the years...

I don't intend to toot my own horn too much, but you might want to check out my es7-membrane project:
https://github.com/ajvincent/es7-membrane/

Alex

From: Michael Lewis <[hidden email]>
To: [hidden email]
Cc: 
Bcc: 
Date: Thu, 30 Mar 2017 13:50:07 -0500
Subject: Proxies fail comparison operator
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

Allen Wirfs-Brock
In reply to this post by Michael Lewis
For background on design goals of ES proxies see https://research.google.com/pubs/archive/40736.pdf 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

Michael Kriegel
In reply to this post by Michael Lewis

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

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.  (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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" class="gmail_msg" target="_blank">+41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

Michał Wadas
In reply to this post by Michael Lewis

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a moz-do-not-send="true" href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02
_______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proxies fail comparison operator

Mark S. Miller-2
The Left Hand of Equals
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02
_______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Loading...