[[Invoke]] and implicit method calls

Brendan Eich brendan at mozilla.com
Wed Sep 11 11:02:47 PDT 2013


> Tom Van Cutsem <mailto:tomvc.be at gmail.com>
> September 11, 2013 7:08 AM
> 1) The [[Invoke]] operation is meant to primarily trap method calls 
> generated by user-code of the form |obj.m(...args)|. This is by far 
> the most common case, and I believe we should not extend [[Invoke]] 
> with additional arguments that are irrelevant to this primary use 
> case. Rather than having a boolean argument, better to statically 
> separate the cases into two separate internal methods.

+a bazillion. Srsly!

> 2) There are a number of places in the spec where [[Invoke]] should be 
> called conditionally, if we know for sure the property is callable.
>
> 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.

This is the toString/valueOf legacy.

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

We have zero evidence based on legacy (i.e. what's deployed).

> 3) For proxy trap invocations I maintain we are still better off with 
> [[Get]] + [[Call]] to keep double-lifting as simple as possible.

Sorry if I missed it: what complicates things if we use [[Invoke]] to 
support double-lifting?

/be


More information about the es-discuss mailing list