On Tue, Sep 24, 2013 at 4:49 PM, Mark S. Miller <[email protected]> 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 <[email protected]> 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
