Discuss
  • [Harmony Proxies] Proxy argument for all traps

[Harmony Proxies] Proxy argument for all traps

# David Bruant (13 years ago)

I have recently been writing some code. I have not had the need for a proxy argument, but found a very close pattern that I thought would benefit from a "proxy" argument Here is a gist ( gist.github.com/1466999 ) with an example of the pattern.

Analysis: The makeProxyWhichCallOnDelete constructor takes a function as argument (farg). It will call farg when the delete trap is called.

In client code, I create a weak map. I create a function (f) which reads the value of the weak map based on its first argument. With this function as argument, I create some proxies with the constructor, assign a value to these proxies in the weak map.

In the implementation in the gist, the delete trap calls farg with the target, but it's a dummy choice. In my particular case, I would like to have the identity of the proxy, not the target.

In the end, my f function is pointless since it can't retrieve the weak map values since it does not play with the right objects.

The use case I derived this pattern from is not problematic because:

  • I initialize the constructor with the target (so I have a reference to it and can use this as weak map key)
  • I create one proxy per target. In cases where either one of these condition is not respected, having access to the proxy identity is required to do something useful.

Of course, having the proxy as argument is not an obligation since we there is the technique of creating the handler, creating the proxy and assign "handler.proxy = proxy;", but it's awkward and does not work with sharing handlers.

# Tom Van Cutsem (13 years ago)

As you note, this looks like a pretty contrived example.

It also looks like the "values" WeakMap and the makeProxy... function are intended to be written independently. In that case, why should the module using the WeakMap expect the "o" parameter passed to the callback to be an object stored in its own WeakMap?

And since you create a new anonymous proxy handler per call to makeProxy..., you might as well store a reference to the proxy in the handler with no additional overhead.

All in all I'm happy with the design we ended up with thus far. It's safer and less confusing (no runaway recursion hazards). The only option the current design prohibits is to use a singleton shared handler that can access the proxy.

Cheers, Tom

2011/12/12 David Bruant <bruant.d at gmail.com>