[[Invoke]] and implicit method calls
allen at wirfs-brock.com
Tue Sep 24 10:54:00 PDT 2013
On Sep 24, 2013, at 10:06 AM, Mark S. Miller wrote:
> I do not know and I do not know what to search on to find out. However, I would guess it is used enough to be a real concern. We documented it at <http://wiki.ecmascript.org/doku.php?id=conventions:safe_meta_programming> for reasons that are not Caja specific. That page followed from Axel's <http://www.2ality.com/2011/11/uncurrying-this.html> which is also not Caja specific. Both have been public advice posted in places prominent to the JS community for a long time. There was also an earlier discussion on es-discuss about exactly this integrity issue, that was again not Caja specific.
> But anyway, another point of my email is that I don't understand what problem you're trying to solve. The reason for using this pattern, rather than the much simpler thing.f(...args) is to take control away from thing. If you give control back to thing anyway, what's the point? If you want thing to have control, why not write thing.f(...args) ?
The main issue is the use case exemplified by:
let temp = thing.f;
//do other stuff using temp
I have previously suggested that the fix for this if [[Invoke]] is used to implement the call operator is:
let temp = thing.f;
//do other stuff temp
In addition, I proposed that where this use case appears in the ES spec ([[Get]]+stuff+[[Call]]) it should be replaced with [[Get]]+stuff+[[Invoke]].
The object to this is that it observably does two property lookups of "f" while [[Get]]+[[Call]] only does one. Personally, I think this is probably a insignificant change from the ES5 semantics, but trying to avoid it is one of the forces pushing towards using [[InvokeFunction]].
A separate concern is that even though in ES6 thing.f(...ags) is probably better than temp.call(thing,...args) it isn't the pattern existing JS programmers use.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss