[[Invoke]] and implicit method calls
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
More information about the es-discuss