[[Invoke]] and implicit method calls
jason.orendorff at gmail.com
Thu Sep 12 00:36:39 PDT 2013
On Wed, Sep 11, 2013 at 8:30 PM, Waldemar Horwat <waldemar at 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().
More information about the es-discuss