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

Tom Van Cutsem tomvc.be at gmail.com
Tue Mar 1 02:10:41 PST 2011


Hi,

I had also thought of this, but quickly discarded it as too imperative. It
just seems like a bad idea, and it interacts horribly with nested handler
traps (you'd need to maintain a stack of "currentProxies" to make traps
reentrant) and functional idioms (anonymous closures defined within a trap
won't capture the current value of "currentProxy" as they would if it were a
formal parameter to the trap).

Another way of looking at this: your suggestion implements a dynamically
scoped binding, passing "proxy" as a parameter to the trap implements a
lexically scoped binding. The latter is almost always what you want.

Cheers,
Tom

2011/2/28 David Bruant <bruant at enseirb-matmeca.fr>

>  Hi,
>
> After reading this page (
> http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy),
> 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.currentProxy is 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 defined.
>
> On issue is that within a handler method, I could do:
> {keys: function(){
>     Object.defineProperty(this, 'currentProxy', {value: 'gotcha',
> configurable:false});
>     }
> }
> 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 deleted.
>
> 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.
>
> David
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110301/a1f3cb03/attachment.html>


More information about the es-discuss mailing list