[Harmony proxies] Another idea to give handler access to proxies

David Bruant bruant at enseirb-matmeca.fr
Mon Feb 28 12:21:35 PST 2011


After reading this page
I thought of another idea.
Maybe that instead of adding an argument to all handler methods, we
could add a property to the handler.
Each time a proxy p method m is trapped (with handler h):
- Object.defineProperty(h, 'currentProxy',  {value: p, configurable:true})
- call the m trap (which can freely use this.currentProxy)
- delete h.currentProxy (that's why the property has to be configurable)

An implementation could run some static analysis to see if the handler
is an actual object and if this.currentProxyis actually used in the trap
to avoid the overhead of define+delete. They would have to be performed
if the handler is itself a proxy.
In order to reserve the 'currentProxy' (no strong conviction on the
name. It could also be 'proxy') name, Proxy.create and
Proxy.createFunction could throw an error is such a property is already

On issue is that within a handler method, I could do:
{keys: function(){
    Object.defineProperty(this, 'currentProxy', {value: 'gotcha',
This is notoriously stupid, but it would make the "inner delete" throw
an error. The issue I'm raising is that 'configurable' controls both the
fact that a property can be redefined through Object.defineProperty and

Anyway, this solution sweeps away any argument positionning issue. It is
very generic and for sure, any trap current or future will need access
to the proxy, so it solves the problem for potential future traps.
On the other hand, there may be some property configuration issues and
maybe some performance issue since the two additional calls may be
needed at each trap call (even though static analysis could help out
with this).

This idea is unperfect like the others, but it might be worth
investigating in that direction.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110228/7780d235/attachment.html>

More information about the es-discuss mailing list