On Wed, Sep 11, 2013 at 8:30 PM, Waldemar Horwat <walde...@google.com> wrote: > On 09/11/2013 03:38 PM, Jason Orendorff wrote: >> But as Allen said, [[Invoke]] is not a performance hack. It's a >> correctness hack. >> >> It permits proxies to customize their behavior around `this`, and even >> naive .invoke trap users would definitely want those customizations to >> apply for implicit .toString() and .then(). > > Except that [[Invoke]] doesn't solve the correctness problem either. As we > discussed at a prior meeting, it fails in the case of passing 'this' as one > of the arguments.
The specific correctness problem [[Invoke]] addresses is the ability for a proxy to maintain both 1. `proxy.method` behaves like `target.method`; and 2. `proxy.method()` behaves like `target.method()`. But you’re right, even with [[Invoke]], a proxy cannot further maintain that 3. `proxy.method.bind(proxy)` behaves like `target.method.bind(target)` or any number of other desirable properties. [[Invoke]] is skin deep. I didn’t say [[Invoke]] solved “the correctness problem”, as if there’s only one. Proxies are correctness problem factories. I don’t know if there’s a single possible use of proxies with a comprehensive, easily expressible correctness criterion that actually holds. Proxies are all about “good enough”. Given that, skin-deep [[Invoke]] makes more sense. It causes the defaults to behave as expected in some rather basic, important cases. There are going to be a lot of Proxy use cases where the programmer has not the slightest interest in any kind of algebraic law like the above. There will be a lot of proxy handlers that only have .get(). -j _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
