[[Invoke]] and implicit method calls

Mark S. Miller erights at google.com
Tue Sep 24 07:37:53 PDT 2013

Thanks to André and Tom, I think I now understand the problem. I think the
only solution lies in this comment from Tom:

On Tue, Sep 24, 2013 at 1:23 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:

> [...] The generic solution is membranes. Anything else needs
> application-specific consideration.

But right above it he says

To solve all of that, you'd need proper membranes. But using membranes to
> fix the this-rebinding problem seems like total overkill.

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,

In answer to Tom's later question, Caja code does use the pattern


a lot. Or even

// At initialization time, before the primordials may be corrupted. See
// <http://wiki.ecmascript.org/doku.php?id=conventions:safe_meta_programming
   var bind = Function.prototype.bind;
   var uncurryThis = bind.bind(bind.call);
   var fUncurried = uncurryThis(Thing.prototype.f);

// At runtime, after the primordials may be corrupted, but reliably
// still in the lexical scope of our fUncurried binding
   var reliableFResult = fUncurried(thing, ...args);

which presents all the same issues more indirectly. It does this usually
for purposes of integrity on the meaning and results of the call -- that it
is reliably according to the original f function's behavior, and no longer
according to thing. When we want thing to be in control of the meaning of
the operation, we do thing.f(...args). Usually, the entire reason for this
pattern is to take this control away from thing.

Whatever problem InvokeFunction is trying to solve, solve it with
membranes, or, as Tom says, in an application-specific manner rather than a
generic mechanism.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130924/7f7313e7/attachment-0001.html>

More information about the es-discuss mailing list