[[Invoke]] and implicit method calls

Till Schneidereit till at tillschneidereit.net
Tue Sep 10 10:48:43 PDT 2013


On Tue, Sep 10, 2013 at 7:45 PM, Jason Orendorff
<jason.orendorff at gmail.com>wrote:

> 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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130910/dcf3f163/attachment.html>


More information about the es-discuss mailing list