Help wanted: Membrane proxies + Object.freeze() == paradox

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Help wanted: Membrane proxies + Object.freeze() == paradox

Alex Vincent
Full details are at https://github.com/ajvincent/es7-membrane/issues/79 , which is where I'm hoping to find a solution.

In short:  if
  1. I have a function wetB() and an instance of wetB called wet_b,
  2. I call Object.freeze(wet_b);
  3. I create matching "membrane" proxies for wetB and wet_b named dryB and dry_b,

Then:

  • Reflect.get(wetB, "prototype") === Reflect.getPrototypeOf(wet_b)
  • Reflect.get(dryB, "prototype") !== Reflect.getPrototypeOf(dry_b)

This is a paradox:  I claim that what's true on the "wet" object graph should be true on the "dry" object graph.

Please, if you can offer help on this to fix the sample code I've posted, or if you can confirm that my claim above is incorrect and never can be correct, I'd appreciate it.

Alex Vincent

Hayward, CA, USA


--
"The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

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

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

Boris Zbarsky
On 5/23/17 3:44 AM, Alex Vincent wrote:
>  3. I create matching "membrane" proxies for wetB and wet_b named dryB
>     and dry_b,

Shouldn't you also have a proxy for webB.prototype (called dryproto,
let's say)?  Otherwise your "wet" and "dry" object graphs are actually a
single kind of weird object graph...

> Then:
>
>   * Reflect.get(wetB, "prototype") === Reflect.getPrototypeOf(wet_b)
>   * Reflect.get(dryB, "prototype") !== Reflect.getPrototypeOf(dry_b)

And then Reflect.get(dryB, "prototype") === dryproto ===
Reflect.getPrototypeOf(dry_b), I would hope.

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

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

Jason Orendorff
In reply to this post by Alex Vincent
On Tue, May 23, 2017 at 2:44 AM, Alex Vincent <[hidden email]> wrote:
Full details are at https://github.com/ajvincent/es7-membrane/issues/79 , which is where I'm hoping to find a solution.

To fix this, you must create a third object for each dry proxy, to serve as its [[ProxyTarget]]. There's no way around it. And you're right, it's not easy; you have to implement all of the handler methods, because none of the defaults do the right thing anymore.

All the target checks in the design were intended to (a) allow proxies to claim to have immutable parts; and yet (b) maintain the language's invariants that immutable parts cannot change, even for proxies.  [[ProxyTarget]] looks like an ease-of-use feature, but it's not; it's really in support of (a) and (b), and as you've found, it actually makes some things harder.

-j


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

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

Mark S. Miller-2
Take a look at Tom's explanation of the "shadow target" technique at
section 4.3



On Tue, May 23, 2017 at 8:45 AM, Jason Orendorff <[hidden email]> wrote:
On Tue, May 23, 2017 at 2:44 AM, Alex Vincent <[hidden email]> wrote:
Full details are at https://github.com/ajvincent/es7-membrane/issues/79 , which is where I'm hoping to find a solution.

To fix this, you must create a third object for each dry proxy, to serve as its [[ProxyTarget]]. There's no way around it. And you're right, it's not easy; you have to implement all of the handler methods, because none of the defaults do the right thing anymore.

All the target checks in the design were intended to (a) allow proxies to claim to have immutable parts; and yet (b) maintain the language's invariants that immutable parts cannot change, even for proxies.  [[ProxyTarget]] looks like an ease-of-use feature, but it's not; it's really in support of (a) and (b), and as you've found, it actually makes some things harder.

-j


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

Alex Vincent
Yes, I've been using the shadow technique in my es7-membrane project for quite some time.  I was trying to minimize a fairly complex test case here.

Obviously, I can reintroduce shadow targets into the minimal testcase, but then I need to figure out how to make the prototype object I'm trying to get consistent again... still working through the details of that in my head.

On Tue, May 23, 2017 at 8:50 AM, Mark S. Miller <[hidden email]> wrote:
Take a look at Tom's explanation of the "shadow target" technique at
section 4.3

--
    Cheers,
    --MarkM


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

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

Jason Orendorff
I think the most straightforward thing is something like this:


To restate the obvious, this is a minimal fix for your minimized test case, not production code you can take and use. You'd need to implement all the rest of the handler methods.


On Tue, May 23, 2017 at 11:01 AM, Alex Vincent <[hidden email]> wrote:
Yes, I've been using the shadow technique in my es7-membrane project for quite some time.  I was trying to minimize a fairly complex test case here.

Obviously, I can reintroduce shadow targets into the minimal testcase, but then I need to figure out how to make the prototype object I'm trying to get consistent again... still working through the details of that in my head.

On Tue, May 23, 2017 at 8:50 AM, Mark S. Miller <[hidden email]> wrote:
Take a look at Tom's explanation of the "shadow target" technique at
section 4.3

--
    Cheers,
    --MarkM



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

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

Alex Vincent
Thanks, Jason.  I tried that approach last night (calling setPrototypeOf within the getPrototypeOf trap), and it caused a nasty regression in one of my other prototype-checking tests.  I assumed at the time that I had done something wrong, but your quick summary shows that instead I was doing something right, and that my prototype chain handling was incorrectly implemented...

On Tue, May 23, 2017 at 9:26 AM, Jason Orendorff <[hidden email]> wrote:
I think the most straightforward thing is something like this:


To restate the obvious, this is a minimal fix for your minimized test case, not production code you can take and use. You'd need to implement all the rest of the handler methods.


On Tue, May 23, 2017 at 11:01 AM, Alex Vincent <[hidden email]> wrote:
Yes, I've been using the shadow technique in my es7-membrane project for quite some time.  I was trying to minimize a fairly complex test case here.

Obviously, I can reintroduce shadow targets into the minimal testcase, but then I need to figure out how to make the prototype object I'm trying to get consistent again... still working through the details of that in my head.

On Tue, May 23, 2017 at 8:50 AM, Mark S. Miller <[hidden email]> wrote:
Take a look at Tom's explanation of the "shadow target" technique at
section 4.3

--
    Cheers,
    --MarkM





--
"The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

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