<div dir="ltr">On Thu, Sep 12, 2013 at 12:38 AM, Jason Orendorff <span dir="ltr"><<a href="mailto:jason.orendorff@gmail.com" target="_blank">jason.orendorff@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Sep 11, 2013 at 9:08 AM, Tom Van Cutsem <<a href="mailto:tomvc.be@gmail.com">tomvc.be@gmail.com</a>> wrote:<br>

> Currently the pattern for this is [[Get]]+[[Call]]. We cannot refactor to<br>
> [[Has]] + [[Invoke]] in general, because [[Has]] will return true also for<br>
> non-callable values.<br>
><br>
> If we believe these are call-sites where it is worth avoiding the allocation<br>
> of a function, then having an additional internal method like [[GetMethod]]<br>
> or [[InvokeConditional]] makes sense, but I doubt it's worth the added<br>
> complexity.<br>
<br>
</div>But as Allen said, [[Invoke]] is not a performance hack. It's a<br>
correctness hack.<br>
<br>
It permits proxies to customize their behavior around `this`, and even<br>
naive .invoke trap users would definitely want those customizations to<br>
apply for implicit .toString() and .then().<br></blockquote><div><br></div><div>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.<br>
</div></div></div></div>