[Harmony proxies] Revisiting the forwarding proxy pattern

David Bruant david.bruant at labri.fr
Tue Mar 22 08:07:33 PDT 2011


Hi,

I'd like to discuss forwarding proxy patterns. I'll call "full handler"
a handler with all current traps and "own handler" a handler with just
the own properties layer traps.
The current forwarding proxy pattern is:
---
var p = Proxy.create(fullForwardingHandler(target));
---
Any interaction with p is delegated to target.
To visualize the prototype chain, we have:
-------
p --> null
target --> Object.getPrototypeOf(target) --> ... --> null
-------
Notably, all prototype-climbing calls are delegated to the target
prototype chain regardless of what p prototype is (I'll get back to that
later)

We have seen a limitation of providing a full forwarding handler
systematically
(http://wiki.ecmascript.org/doku.php?id=strawman:derived_traps_forwarding_handler).
Regardless of what is decided on the strawman, some people may want to
only provide own traps. One "lighter" way to provide the same forwarding
handler would be to do:
var p = Proxy.create(ownForwardingHandler(target),
Object.getPrototypeOf(target));
Which would visualize as:
---
p -----------
             \
target --> Object.getPrototypeOf(target) --> ... --> null
---
So at the own layer, p and target act exactly the same. They also act
the same when it comes to inheritance but not thanks to prototype
climbing traps. They do so because they natively delegate to the same
prototype object and use the default trap behavior. So, they are also
consistent with instanceof and Object.getPrototypeOf (and the prototype
is correct when the proxy is fixed which is a consistent side-effect.
This doesn't happen with current full forwarding and null prototype).

Ok, now that we are able to be in sync only at the own layer, one
interesting pattern is the following
---
p --> Object.getPrototypeOf(p) --> ... --> null
target --> Object.getPrototypeOf(target) --> ... --> null
---
with p and target in sync at the own layer. For all own operations, p
would forward to target, however, for all proto-climbing operations p
would use its own properties. Actually, this works without any effort
with the OwnForwardingHandler since its default derived traps delegate
to the correct prototype by default.
This pattern could be used for a new prototype inheritance pattern where
o1 could inherit from p, o2 from target. They would both feel they
inherit from the same object (since p and target are in sync) while, one
step further inheriting from completely different objects.

All of this is just a discussion on the forwarding proxy pattern. But I
think it was worth pointing the potential limitations of how this
pattern is currently presented (limitations which are different from the
one previously noticed which led to
strawman:derived_traps_forwarding_handler).

David


More information about the es-discuss mailing list