[[Invoke]] and implicit method calls

Till Schneidereit till at tillschneidereit.net
Tue Sep 24 11:59:25 PDT 2013


Well, yes, but only if we commit to keeping it around. Which we'd probably
not want to do if .invoke is removed from the spec for good.


On Tue, Sep 24, 2013 at 8:54 PM, Brendan Eich <brendan at mozilla.com> wrote:

> You will get some migration from __noSuchMethod__, I predict, among
> hobbyists and fans willing to write SpiderMonkey-specific code (or who
> wrote it in the past, possibly a while ago, and who want to keep it going).
>
> /be
>
>  Till Schneidereit <mailto:till at tillschneidereit.**net<till at tillschneidereit.net>
>> >
>> September 24, 2013 11:53 AM
>>
>>
>>     Based on all the great input (thanks to André for his summary, and
>>     Mark for pointing out "works always" beats
>>     "half-works/half-broken"), and talking to Allen 1:1, I'm back to
>>     status quo ante: we are better off being conservative designers by
>>     deferring invoke.
>>
>>     If we need to trial it as a strawman extension in SpiderMonkey, we
>>     can do that, and we'll report back.
>>
>>
>> FWIW, our implementation isn't too far off. I have some feedback to
>> integrate still, and probably some rebasing by now, but getting it into the
>> tree shouldn't be too hard. I don't however, know who would use it and give
>> us feedback. Other than Shumway, that is, where the use case is very clear
>> and won't give us much new information.
>> Brendan Eich <mailto:brendan at mozilla.com>
>> September 24, 2013 11:38 AM
>> Based on all the great input (thanks to André for his summary, and Mark
>> for pointing out "works always" beats "half-works/half-broken"), and
>> talking to Allen 1:1, I'm back to status quo ante: we are better off being
>> conservative designers by deferring invoke.
>>
>> If we need to trial it as a strawman extension in SpiderMonkey, we can do
>> that, and we'll report back.
>>
>> /be
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
>> September 24, 2013 10:54 AM
>>
>>
>>
>> The main issue is the use case exemplified by:
>>
>> let temp = thing.f;
>> //do other stuff using temp
>> temp.call(thing,...args)
>>
>> 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
>> thing.f(...args)
>>
>> 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.
>>
>> Allen
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>> Mark S. Miller <mailto:erights at google.com>
>> September 24, 2013 10:06 AM
>> 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<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<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) ?
>>
>>
>>
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
>> September 24, 2013 9:47 AM
>>
>>
>>
>> Mark,
>>
>> In the wild, how often do you think F.p.call is used with these sorts of
>> integrity guarantees in mind?  Does anybody other than Caja do it?   If we
>> are really only talking about Caja, it presumably could adapt to using
>> Reflect.apply.
>>
>> Allen
>>
>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130924/3dd3c8cd/attachment.html>


More information about the es-discuss mailing list