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 <[email protected]> > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
