[[Invoke]] and implicit method calls

Tom Van Cutsem tomvc.be at gmail.com
Wed Sep 11 07:08:37 PDT 2013

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.

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.

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.

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


2013/9/11 Till Schneidereit <till at tillschneidereit.net>

> On Wed, Sep 11, 2013 at 4:44 AM, Brendan Eich <brendan at mozilla.com> wrote:
>> Except http://ariya.ofilabs.com/2011/**08/hall-of-api-shame-boolean-**
>> trap.html<http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html>
>> .
> So one thing we could potentially do is to say that a proxy trapping
> [[Invoke]] either always returns  [invokeSuccess, result] and doesn't need
> the boolean argument - or it's just never conditional: if you trap
> [[Invoke]], you have to serve all method calls, and Proxy.[[Invoke]] would
> just return result. Given that proxies users would most likely not be used
> for these corner cases in the majority of cases, and quite deliberately so
> in the others, this seems fine to me.
>> /be
>> Till Schneidereit wrote:
>>>     I'm beginning to like a conditional option on [[Invoke]].
>>>     Consider: [[Invoke]](P, ArgumentsList, Receiver, conditional=false)
>>>     If conditional is false, it works just like the current [[Invoke]]
>>>     spec.
>>>     If conditional is true and the [[Get]] value is not callable (this
>>>     includes undefined for a missing property) result is: [false,
>>>     [[Get]] result].
>>>     if conditional is true and the [[Get]] value is callable, result
>>>     is [true, value returned from [[Call]]
>>>     The conditional form would only be used  in odd cases like the
>>>     toJSON call.
>>>     ES code can accomplish the same thing via Reflect.invoke with true
>>>     as the 4th argument.
>>> I like it. This gets around the issue of distinguishing a return value
>>> of `undefined` from "no callable property with that name found" and would
>>> be easy to implement for proxies, too.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130911/fbbd526f/attachment.html>

More information about the es-discuss mailing list