[[Invoke]] and implicit method calls

Till Schneidereit till at tillschneidereit.net
Wed Sep 11 15:42:46 PDT 2013

On Thu, Sep 12, 2013 at 12:38 AM, Jason Orendorff <jason.orendorff at gmail.com
> 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
> > complexity.
> 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().

I agree, anything else would be surprising. But can't we make the .invoke
trap work for both [[Invoke]] and [[InvokeConditional]]? It would just
always be called, and the places where [[InvokeConditional]] is used in the
spec would treat it as though the required method exists on the receiver.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130912/321a5eb8/attachment-0001.html>

More information about the es-discuss mailing list