[[Invoke]] and implicit method calls
allen at wirfs-brock.com
Fri Sep 20 12:36:45 PDT 2013
On Sep 20, 2013, at 4:20 AM, Brendan Eich wrote:
> But this makes proxies for special purpopes strictly harder to write, even with a base handler implementation. Please correct me if I'm mistaken.
> So I think we are better off with get+invoke, but I'm still troubled by the double lookup.
It think it is useful to consider the double lookup issue from the perspective of what a JS programmer might code.
If naive JS programmer might do a conditional method call like:
if ("name" in obj) obj.name();
This has a double lookup which would be observable if the "name" property is a getter or if obj is a proxy. However, assuming that we have the [[Invoke]] MOP operation, things works as expected if obj is a transparently forwarding Proxy.
A a programmer who was a bit more sophisticated might code:
if (typeof obj.name == "function") obj.name();
but they still have the double lookukp and things still work ok is obj is a transparent proxy.
It is only when you get to the sophistication level of:
if (typeof (func=obj.name) == "function") func.call(obj. is is);
that the double lookup goes away. However, as currently specified, you won't get the expected result if obj is a forwarding proxy.
> Any thoughts on parameterizing invoke by (id | func)?
Waldamar raised this concern about the difference between [[Get]]+[[Call]] and [[Invoke]] at the June TC39 meeting.
In a private email to Tom I suggested the paramaterized [[Invoke]] solution
On Jul 30, 2013, at 10:11 AM, Allen Wirfs-Brock wrote:
> I wonder if we could respecify F.p.call/apply in a manner that would make David's getMonth.call use case work (at least some of the time).
> [[Invoke]](P, ArgumentsList, Receiver) is current specified such that P must be a property key. What if we modify that so that P can be either a property key or a callable and that when a callable is passed the [[Get]] steps are skipped and P itself is used as the method.
> Then call/apply could be respecified in terms of [[Invoke]] and ForwardingHandler could do the appropriate handler substitution.
> Of course, this is only an asymptotically better solution, as it only improves the handler of Proxy objects in the this position. It wouldn't, may itself, fix Array.isArray.
> What do you think?
I still like this solution. At the JS level of abstraction it makes all of the explicit JS forms above work consistently with transparently forwarding proxies.
Probably the novel aspect WRT to this thread is the idea that [[Invoke]] parameterized by a function instead of a property key should be used i the implementations of Function.prototype.call/apply.
As an alternative, we could have both [[Invoke]] and [[InvokeFunction]] but I really prefer having one [[Invoke]] MOP operation and trap rather than two.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss