[[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
> f.call(obj)
> 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;
// later:

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 */
// later:

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
should confirm.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130924/872df968/attachment.html>

More information about the es-discuss mailing list