July TC39 meeting notes, day 1
david.bruant at labri.fr
Thu Jul 28 01:35:57 PDT 2011
Le 28/07/2011 06:21, Brendan Eich a écrit :
> == Handler access to proxies ==
> Proxy handler traps need to receive the proxy as a parameter: first, or last?
> Last allows trap implementors to leave |proxy| off. It's also a compatible extension to the proposal and its prototype implementations. Putting |proxy| last may also steer implementors away from touching proxy, reducing the bugs where you infinitely diverge.
> First is more normal-order (proxy, name) and some find it more aesthetically pleasing.
> Another alternative: the proxy could be "passed" via a data property on the handler.
I think we discussed already the idea of "proxy" being passed as a data
property to the handler and came to the conclusion that it may not be a
good idea, because it breaks the stratification. If two proxies use the
same handler as in , then, there is an ambiguity on what the value of
this property should be.
> But the only use for the proxy reference is as a key in a weakmap,and if the handler references it, the handler could just as well be the key -- or the handler could simply hold the value associated by the weakmap.
There is at least one cases other than the weakmap-key one which is to
obtain Object.getPrototypeOf(proxy) within a trap. With a handler
reference instead of a proxy reference, it is not impossible, but
requires some additional work as in  (I provide a reference to the
proxy to use it later to get the prototype). In my opinion at least all
traps emulating an inheritance-related trap should have a reference to
For the same reason than previously, the prototype could not be a data
property of the handler as several proxies could use the same handler
with different prototypes.
> Conclusion: no rationale for adding a |proxy| parameter to all traps.
I felt that there really was a need for a proxy parameter in all traps,
but can't find a use case (besides the weakmap-key one) for why at the
> == Proxy drop receiver ==
> Sean Eagan pointed out in
> 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.
I'm glad :-)
Also, Microsoft enthousiasm toward proxies makes me happy!
Thanks for the meeting notes!
More information about the es-discuss