This can also be seen by realizing that if proxyA's handler uses the default "get" and "set" trap implementations, and proxyB is proxyA's [[Prototype]], then proxyB's "get" and "set" traps will not be called due to property access on proxyA, but rather its "getPropertyDescriptor" trap.
Thanks, Sean Eagan On Wed, Apr 27, 2011 at 1:55 PM, David Bruant <david.bru...@labri.fr> wrote: > Oh ok, sorry. So in that case, this is something that has been discussed > already a couple of times. The internal object API is a bit inconsistent > with proxy traps intentions, especially when it comes to recursive calls > to traps on the prototype. > If I recall correctly, Allen Wirfs-Brock is working on rewriting object > internal methods so that they are both semantically equivalent to what > we know and coherent with what we expect from proxies. > Maybe we should start filing bugs on the topic at > https://bugs.ecmascript.org/ ? I believe in this particular case that ES5 already has the correct / coherent / expected behavior, the bug happens to be with the proxy proposal passing the "receiver" argument. When an author creates an object (or proxy) x, and sets its [[Prototype]] to an object (or proxy) y, they are not granting access to x to y. Since proxies are supposed to be as transparent as possible, if y happens to be a proxy, the author may not even know this, and so would be surprised to know that it now has leaked a reference to x. Also, the behavior I have stated as correct matches the default "get" and "get" trap implementations. If proxyA's handler uses the default "get" and "set" trap implementations, and proxyB is proxyA's [[Prototype]], then proxyB's "get" and "set" traps will not be called on property access to proxyA, but rather its "getPropertyDescriptor" trap. Thanks, Sean Eagan _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
