[[Invoke]] and implicit method calls
Tom Van Cutsem
tomvc.be at gmail.com
Tue Sep 24 03:51:13 PDT 2013
2013/9/24 Mark S. Miller <erights at google.com>
> Ok, I've only been skimming the thread but I obviously missed something
> crucial. How would
> cause obj's handler to be invoked at all, much less be given access to f?
> And why?
This is exactly the hazard I alluded to in earlier mails. Thanks to Kevin
for the more tangible example, and to André for the accurate summary.
It seems we are faced with the following dilemma:
1) There is code in the wild of the form:
var f = obj.method;
If obj is a transparent forwarding proxy, the expectation is for this call
to work. Here is a call that is *intended* to be polymorphic, but because
of funarg extraction, loses the intended polymorphism. [[InvokeFunction]]
would fix this.
2) There is code in the wild of the form:
var f = /* some closely held function, or an original built-in known only
to work on objects of a certain type */
The expectation of this code is that the f function is called (and only its
code runs), regardless of whether obj is a proxy or not. In particular, if
obj is a proxy, we do not want to transfer control to the proxy, and we
most certainly don't want to expose f to the proxy. This code *really*
means to make a non-polymorphic function call.
Both pieces of code are using Function.prototype.call, with opposite
expectations. Obviously we cannot fix both. The status-quo breaks pattern
#1 but keeps pattern #2 intact.
Reflect.apply is indeed "the new [[Call]]" but only addresses the issue
after the fact. Can we break pattern #2?
I believe Caja uses pattern #2 but MarkM or someone else from the Caja team
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss