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?
>
> allen
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.
Allen_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
