Discuss
  • proxies: receiver argument and object maps

proxies: receiver argument and object maps

# David Herman (14 years ago)

Forgive me that I've not kept track of where we are in the discussion about the additional receiver argument.

I think I just found a pretty important use case for the receiver argument. Say you want to keep some information about a proxy object in a Map or a WeakMap, and you want the handler to be able to access that information. Then you're going to need the proxy object to do it.

I suppose you can close over the proxy value:

var proxy;
var handler = { ... proxy ... };
proxy = Proxy.create(handler);

But then you have to make a fresh handler for each instance.

# David Bruant (14 years ago)

Le 16/10/2011 23:02, David Herman a écrit :

Forgive me that I've not kept track of where we are in the discussion about the additional receiver argument.

I think I just found a pretty important use case for the receiver argument. Say you want to keep some information about a proxy object in a Map or a WeakMap, and you want the handler to be able to access that information. Then you're going to need the proxy object to do it.

I suppose you can close over the proxy value:

var proxy;
var handler = { ... proxy ... };
proxy = Proxy.create(handler);

But then you have to make a fresh handler for each instance.

There are 2 different things:

  1. the receiver object. This one may only be useful in case of inheritance:

var p = Proxy.create(someHandler);

var o1 = Object.create(p); var o2 = Object.create(p);

o1.a; o2.a;

here, both o1 and o2 delegates their "get" to the proxy... so we thought. Sean Eagan started a thread which conclusion was based on the semantics of [[Get]], you never call the [[Get]] of the prototype, but rather its [[GetProperty]] internal. Consequently, you never need the receiver. Not even for the tricky case of getter/setter binding. See strawman:proxy_drop_receiver

But in my event as property experiment, I have found that I actually need that I need the receiver object somewhere to properly implement inherited events. I'll post on es-discuss as soon as I'm done to make my case and argue back in favor of receiver.

  1. the proxy object It seems to be what you're describing Several arguments and experiments have been made proving that proxy as an argument was necessary for all traps. See strawman:handler_access_to_proxy

I think we're waiting for the November TC39 meeting for decisions to be made regarding proxies.

# David Herman (14 years ago)

D'oh -- of course, you're right. The use case I'm describing wants the proxy, not the receiver.

Thanks,

# David Bruant (14 years ago)

Le 16/10/2011 23:02, David Herman a écrit :

Forgive me that I've not kept track of where we are in the discussion about the additional receiver argument.

I think I just found a pretty important use case for the receiver argument. Say you want to keep some information about a proxy object in a Map or a WeakMap, and you want the handler to be able to access that information. Then you're going to need the proxy object to do it.

I suppose you can close over the proxy value:

var proxy;
var handler = { ... proxy ... };
proxy = Proxy.create(handler);

But then you have to make a fresh handler for each instance.

Also, a temporary solution to have access to the proxy without is being an argument is to put it as a property of the handler. Example: DavidBruant/HarmonyProxyLab/blob/master/LazyReadCopy/LazyReadCopy.js#L84

Actually, an object is created with the handler as prototype. this object gets an own "proxy" property and this is the object that is used as handler. I think that Tom gets credit for this idea.

# David Herman (14 years ago)

Yeah, actually, that's roughly what I just ended up doing. I was just playing with the idea of creating pollution-free dictionaries using proxies, and came up with this:

https://github.com/dherman/dictjs

The biggest issue, though, is the toString/valueOf one I describe in the other message I sent this afternoon.

(Well, that and performance, which quite possibly sucks. So this may not be a viable idea. It was an interesting experiment, anyway.)