[[Invoke]] and implicit method calls

Till Schneidereit till at tillschneidereit.net
Tue Sep 24 07:56:14 PDT 2013


On Tue, Sep 24, 2013 at 4:49 PM, Mark S. Miller <erights at google.com> wrote:

> I would have no objections to dropping it. For me, the Invoke trap is
> merely another derived trap whose main use is to avoid allocations needed
> when relying only on more fundamental traps. See <
> https://mail.mozilla.org/pipermail/es-discuss/2013-September/033501.html>.
> These extra allocations are cheaper than the confusion caused by trying to
> use the Invoke traps for other purposes.
>
>
> On Tue, Sep 24, 2013 at 7:43 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>
>>
>>> A solution that works is better than one that doesn't. We always knew
>>> that patterns of proxies short of membranes would have abstraction leakage.
>>> This is one. What is wrong with the stance: Live with it or use membranes,
>>>
>>
>> I think I agree with this stance.  Does that imply that we should drop
>> the invoke trap, then?
>>
>
I think this is a false dilemma. The problems with an .invokeFunction trap
don't have much to do with the .invoke trap. In fact, I'd argue that the
two solve similar, but distinct issues: .invokeFunction gives proxies the
ability to intervene whenever a function is called with the proxy as the
receiver. .invoke gives it the ability to return a result *instead of* a
function being called with the proxy as a receiver.

Fundamental issues with trapping [[InvokeFunction]] (which I think have
been clearly demonstrated) don't really affect trapping [[Invoke]]. Neither
does .invoke solve the issues .invokeFunction is meant to solve, but it
doesn't need to in order to be useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130924/520634d3/attachment.html>


More information about the es-discuss mailing list