Le 26/01/2011 19:17, Brendan Eich a écrit : > 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 Ooooh... right.... Sorry for the confusion.
>>> 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. If you handlers are frozen, there should be no leaking, shouldn't there? (I actually think that freezing the handler should be done in the no-op forwarding proxy example or any handler factory, but that's another issue). About the closure capturing, it works only if one proxy is using the handler. It doesn't if several proxies share it. I think that the problem I raised earlier remaims with receiver in get and set: there is no way to reach the proxy. If there are two proxies in the prototype chain, unless you do some string hackery on them to distinguish them, climbing the prototype chain from receiver won't allow you to know which proxy you're manipulating (which can be embarassing if the handler is shared among your two proxies). > 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. ... what about a trailing proxy parameter? It won't change anything on the C++ side (by comparison to a leading parameter), but will on the JS side, because you can omit the parameter if you don't need it. I fully agree that the proxy isn't useful as a parameter most of the time. However, for the things I've mentionned earlier (Object.getPrototypeOf, distinguishing proxy and function proxy within the handler if it's shared, use of instanceof... all of the object semantics which isn't part of a handler defintion), there is no way to access them without the proxy argument (and the closure solution cannot work with shared handlers). I personnaly think that not being able, within the handler to access to the prototype of your proxy, the one you have set, is a loss. It's like if the ES5 object internal methods didn't have access to the [[Prototype]] internal property. David
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
