[[Invoke]] and implicit method calls
allen at wirfs-brock.com
Wed Sep 11 19:02:04 PDT 2013
On Sep 11, 2013, at 6:30 PM, Waldemar Horwat wrote:
> On 09/11/2013 03:38 PM, Jason Orendorff wrote:
>> On Wed, Sep 11, 2013 at 9:08 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>>> Currently the pattern for this is [[Get]]+[[Call]]. We cannot refactor to
>>> [[Has]] + [[Invoke]] in general, because [[Has]] will return true also for
>>> non-callable values.
>>> If we believe these are call-sites where it is worth avoiding the allocation
>>> of a function, then having an additional internal method like [[GetMethod]]
>>> or [[InvokeConditional]] makes sense, but I doubt it's worth the added
>> 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.
Yes, but that's an orthogonal issue.
Using [[Invoke]] trap, a Proxy hander can easily perform shallow translation on arguments as well as on the passed this value. It can even try to do deep translation if it thinks it is appropriate.
But, the issue here isn't about the nature of those possible translations. It's about making sure that if there are any they are consistently applied regardless of how the method invocation was make.
More information about the es-discuss