[[Invoke]] and implicit method calls

Brendan Eich brendan at mozilla.com
Wed Sep 11 10:52:31 PDT 2013


Right, this matches my memory of the evolution and priority-shifting 
rationale.

/be

> Tom Van Cutsem <mailto:tomvc.be at gmail.com>
> September 11, 2013 3:30 AM
>
>     On Sep 10, 2013, at 10:48 AM, Till Schneidereit wrote:
>     > Wasn't a major point in favor of having an [[Invoke]] trap that
>     it wouldn't require returning a function from the trap at all?
>     We'd lose this quality with both of these proposals.
>
>     No, the major motivation was to provide a way to deal with
>     different styles of |this| mapping that are needed for different
>     styles of proxies.  However, the ability to implement a method
>     code without producing a function is a desirable secondary benefit
>
>
> That's not how I would characterize it.
>
> Till's argument is the argument we had identified in favor of an 
> invoke() trap almost from day 1 of the Proxy proposal. It was offset 
> by the desire to keep the invoke = get+call invariant and to avoid 
> non-extractable callable properties. Much later, we figured invoke() 
> was needed to allow proxy handlers to cheaply rebind |this| when 
> intercepting method calls. This tipped the balance in favor of adding 
> invoke(). But the idea of avoiding the creation of a temporary 
> function object is to me at least as important.
>
> Cheers,
> Tom
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> September 10, 2013 11:39 AM
>
> No, the major motivation was to provide a way to deal with different 
> styles of |this| mapping that are needed for different styles of 
> proxies. However, the ability to implement a method code without 
> producing a function is a desirable secondary benefit
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Till Schneidereit <mailto:till at tillschneidereit.net>
> September 10, 2013 10:48 AM
>
>     On Tue, Sep 10, 2013 at 11:11 AM, Allen Wirfs-Brock
>     <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
>     > Having to create a new bound function on every method call seems
>     too expensive.
>
>     Only for proxy method calls, and it's easily optimized away in the
>     default case (i.e. there is no .getMethod handler method).
>
>     (As an aside, exchanges like the above have gotten so frequent they
>     are beginning to feel a bit pro forma. I don't mean to sweep all
>     performance concerns into one pile here.)
>
>     >  But what about:
>     >
>     >  6. Let method = O.[[Get]](P).
>     >  7. ReturnIfAbrupt(method).
>     >  8. If IsCallable(method) is false, throw a TypeError.
>     >  9. Return O.[[InvokeFunction]](method,O, args).
>     >
>     > Using [[InvokeFunction]] the Proxy still mediates the [[Call]]
>     to method but it is assume the [[Get]] step has already been
>     performed and has produced method.
>
>     This is appealing. There are a few things [[GetMethod]] can do that
>     this can't: [[InvokeFunction]] can't be used to make a proxy that
>     mimics the behavior of __noSuchMethod__, for example. I don't think it
>     can mimic ActionScript 3 Proxy.callMethod either.
>
>     If [[InvokeFunction]] is deemed powerful enough, I'm all for it.
>
>
> Wasn't a major point in favor of having an [[Invoke]] trap that it 
> wouldn't require returning a function from the trap at all? We'd lose 
> this quality with both of these proposals.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Jason Orendorff <mailto:jason.orendorff at gmail.com>
> September 10, 2013 10:45 AM
> On Tue, Sep 10, 2013 at 11:11 AM, Allen Wirfs-Brock
> <allen at wirfs-brock.com>  wrote:
>> Having to create a new bound function on every method call seems too expensive.
>
> Only for proxy method calls, and it's easily optimized away in the
> default case (i.e. there is no .getMethod handler method).
>
> (As an aside, exchanges like the above have gotten so frequent they
> are beginning to feel a bit pro forma. I don't mean to sweep all
> performance concerns into one pile here.)
>
>>   But what about:
>>
>>   6. Let method = O.[[Get]](P).
>>   7. ReturnIfAbrupt(method).
>>   8. If IsCallable(method) is false, throw a TypeError.
>>   9. Return O.[[InvokeFunction]](method,O, args).
>>
>> Using [[InvokeFunction]] the Proxy still mediates the [[Call]] to method but it is assume the [[Get]] step has already been performed and has produced method.
>
> This is appealing. There are a few things [[GetMethod]] can do that
> this can't: [[InvokeFunction]] can't be used to make a proxy that
> mimics the behavior of __noSuchMethod__, for example. I don't think it
> can mimic ActionScript 3 Proxy.callMethod either.
>
> If [[InvokeFunction]] is deemed powerful enough, I'm all for it.
>
> -j
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> September 10, 2013 9:11 AM
>
> Having to create a new bound function on every method call seems too 
> expensive. But what about:
>
> 6. Let method = O.[[Get]](P).
> 7. ReturnIfAbrupt(method).
> 8. If IsCallable(method) is false, throw a TypeError.
> 9. Return O.[[InvokeFunction]](method,O, args).
>
> Using [[InvokeFunction]] the Proxy still mediates the [[Call]] to 
> method but it is assume the [[Get]] step has already been performed 
> and has produced method.
>
> Allen
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list