On Jan 26, 2011, at 9:54 AM, David Bruant wrote:
> Le 26/01/2011 17:45, Tom Van Cutsem a écrit :
>>
>> Ok, so Mark and I briefly discussed the implications of making
>> "getPropertyDescriptor" and "getPropertyNames" derived.
>>
>> Here's one issue: if you try and write these traps as methods of some sort
>> of "default" handler as we did for the other derived traps (see
>> <http://wiki.ecmascript.org/doku.php?id=harmony:proxies#trap_defaults>)
>> you'll notice that the handler, by default, has no way of referring to the
>> proxy it's intercepting, hence can't get at its prototype and hence can't do
>> the prototype-chain-walk.
> This problem seems to have occured already for the set and get trap for which
> (like your proposition at the end) has been resolved with adding the proxy as
> an argument (called 'receiver' or 'proxy' depending on the example).
'receiver' is not the same as 'proxy' for get and set -- this is important:
js> function C() {
this.bar = "hi";
}
js>
js> var H = {
has: function (name) {
return name == 'foo';
},
get: function (rcvr, name) {
if (name != 'foo')
return undefined;
print(rcvr instanceof C, rcvr.bar);
return "bye";
},
};
js>
js> C.prototype = Proxy.create(H);
null
js>
js> var c = new C;
js> print(c.foo);
true hi
bye
>> Now, from an implementation point-of-view, this isn't really a problem since
>> the proxy implementation can make the connection between proxy and handler
>> when the trap is called, and thus can do the prototype-chain-walk. It's just
>> that you can't write it out in Javascript itself. Mark argues that
>> therefore, "getPropertyDescriptor" and "getPropertyNames" are still
>> fundamental.
> Tell me if I'm wrong, but I think that one of proxies goal is to enable
> people to write in ECMAScript what they usually can't. If we're starting to
> make things that aren't writable in ECMAScript, we're kind of failing at
> empowering proxy users.
> I'm highly in favor of having default proxies behavior writable in ECMAScript.
+1, +many actually.
On the question of proxy parameters for all traps (well, receiver for get and
set): fewer args are better, and closure capture of proxy by handler avoids
leaking the proxy to handler friends, if that matters. Likewise you can't get
the handler from the proxy.
These aren't absolute arguments, but I remember working through the alternative
of a leading proxy parameter, both as JS hacker using proxies and in terms of
SpiderMonkey's C++ implementation, and it was just bigger and less tidy, for
both "sides" (JS and C++), without enough payoff.
/be_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
