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 [2], 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 [1] (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
the proxy.
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
moment.
== 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.
I'm glad :-)
Also, Microsoft enthousiasm toward proxies makes me happy!
Thanks for the meeting notes!
David
[1]
https://github.com/DavidBruant/HarmonyProxyLab/blob/master/NonExtensibleProxies/NonExtensibleProxies.js#L14
[2] https://github.com/DavidBruant/DeclO/blob/master/DeclO.js
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
