2013/9/24 Mark S. Miller <[email protected]> > 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: f.call(obj); 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: f.call(obj); 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. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
