On Jul 31, 2011, at 1:04 PM, Sean Eagan wrote: > A 'receiver' argument is not needed because it would never be > different than the proxy, and the proxy can either be passed as an > argument or stored either as an own property of the handler, or as a > value keyed by the handler in a weak map, which there seems to have > been TC39 concensus on.
Ok, right -- even without the extra proxy parameter in addition to receiver, dropping receiver makes sense. Sorry to go in a circle on this. It's a trap API change, and I agree with Mark that we need Tom to bless it. > Regarding whether or not a proxy argument should be added, there do > seem to be advantages to passing the proxy as an argument, but I don't > feel particularly strong about it. There is a downside, Mark noted it in the meeting: touching the proxy is highly likely to diverge in runaway recursion. > I do however feel strongly that a > 'proxy' argument should not be added selectively to just the 'get' and > 'set' trap, or any other limited set of traps. There are surely use > cases for accessing the proxy within all traps, so for consistency's > sake it seems the method for accessing the proxy should be the same > across all traps. Agreed. /be > > On Fri, Jul 29, 2011 at 8:13 PM, Brendan Eich <[email protected]> wrote: >> On Jul 29, 2011, at 5:42 PM, Kevin Reid wrote: >> >>> On Fri, Jul 29, 2011 at 15:20, Mark S. Miller <[email protected]> wrote: >>>> ---------- Forwarded message ---------- >>>> From: Brendan Eich <[email protected]> >>>> Date: Wed, Jul 27, 2011 at 9:21 PM >>>> >>>> >>>> == Handler access to proxies == >>> [...] >>>> Conclusion: no rationale for adding a |proxy| parameter to all traps. >>>> >>>> == Proxy drop receiver == >>>> >>>> Sean Eagan pointed out in >>>> >>>> https://mail.mozilla.org/pipermail/es-discuss/2011-April/013916.html >>>> >>>> that the receiver parameter of Proxy handlers' get and set traps is >>>> useless, >>>> due to how these derived traps layer on fundamnetal traps. >>>> >>>> Conclusion: remove |receiver| from these traps. >>> >>> Hi; Mark Miller asked me to post this. I am a developer working on >>> Google's Caja, writing ES5 code which uses proxies for our DOM >>> virtualization. >> >> Thanks, you caught a blatant inconsistency in our reasoning. We used Sean's >> message (linked above) as a reason to remove receiver, that Sean wrote that >> message assuming both proxy and receiver would be parameters to get and set >> traps. Sean demonstrated that the two parameters would always have the same >> value, ergo only one was needed, and since at that time, proxy was >> considered important to keep (and add to all traps), receiver fell under the >> ax. >> >> But as noted higher above, at this week's meeting, we rejected adding proxy >> to all traps, including get and set. Therefore we must keep the receiver >> parameter of those two traps, for the reasons you give. Thanks again! >> >> /be >> >> >>> >>> Suppose a proxy handler wishes to implement the 'set' or 'get' trap in >>> a way similar but not identical to the derived trap — similar in that >>> it obtains a property descriptor (from the getOwnPropertyDescriptor >>> trap or otherwise) and proceeds according to the contents of the >>> descriptor. >>> >>> If the property being accessed is an accessor property, then the >>> descriptor's 'get' or 'set' function should be invoked, *with 'this' >>> being the proxy*. This behavior cannot be implemented purely within >>> the handler object (i.e. without the explicit cooperation of the code >>> calling Proxy.create) unless the proxy is passed to the handler. >>> >>> I consider it a useful principle that it should be possible for an >>> object with a given method (the get/set trap of the handler, here) to >>> implement the same behavior as will be performed by the caller (Proxy) >>> if that method did not exist (the derived trap); therefore, I >>> recommend that the 'get' and 'set' traps should have a parameter which >>> is the proxy. >>> >>> I have no position on whether the proxy parameter should be first or >>> last, or whether other traps should have one. >>> >>> -- >>> Kevin Reid >>> (Google intern) >>> <http://switchb.org/kpreid/> >>> _______________________________________________ >>> 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 >> > > > > -- > Sean Eagan _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
