[[Invoke]] and implicit method calls, once more

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Oct 18 11:01:17 PDT 2013


On Oct 18, 2013, at 8:24 AM, Jason Orendorff wrote:

> I can't remember the conclusion of the earlier thread on this topic.
> 
> The question was about how implicit method calls should interact with
> proxies in places (like
> [ToPrimitive](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-toprimitive))
> where the spec first checks that the desired method exists and is
> callable, then calls it.
> 
> I seem to recall the result was either:
> 
>    1. don't change anything; or
> 
>    2. change those places to do [[Get]], if IsCallable, [[Invoke]]
> instead of [[Get]], if IsCallable, [[Call]].
> 
> but the thread sort of trailed off.

Tom, Mark and I has a private conversation about this and some related issues.

Mark made some strong points:

On Sep 24, 2013, at 12:48 PM, Mark Miller wrote:

> ...
> We've said from the beginning that Proxies are not intended as an API to be used directly by non-experts. We've said that it is to be used by experts to create simpler abstractions (like membranes and caretakers) to be used by non-experts.
> 
> Where we're getting into trouble is
> * trying to make the API itself directly usable by non-experts.
> * trying to make the abstraction less leaky for non-membrane use cases where it will necessarily be somewhat leaky anyway.
> 
> ...
> What your question does help me be more decisive on: We should not be in a rush to add an Invoke, InvokeFunction, or any new traps not needed for membranes, and not subject to a long history of examination. Invoke at least, as a derived trap, can always be added later, after ES6. As for the handler hierarchy, I don't yet have an opinion about postponing some of this, but perhaps. We should certainly look at it again with such postponement in mind.

 and this message is a good summary of conclusions that we could agree on:

On Sep 25, 2013, at 1:30 AM, Tom Van Cutsem wrote:

> However, I'm also sympathetic to your argument of keeping the current design minimal, allowing us to extend where necessary based on experience.
> 
> Specifically w.r.t. the 3 points you mention:
> 
> * I agree we can postpone the invoke() trap. It can be added later, perhaps in another form.
> 
> * I agree we can postpone the Handler hierarchy, for the following reasons:
> - This is a fairly large API design. We have many subtle knobs to turn, and we don't yet know which ones will turn out to be the most important.
> - We should give the community the opportunity to experiment before settling on a standardized API.
> - All the code in the proposed Handler API can be fully self-hosted (I have a working implementation on GitHub).
> 
> * Revocable proxies we should keep. Without them, you can't build revocable references (or membranes) that inform the GC their target is no longer live.

This is a place that I'm quite comfortable with WRT to the spec.  It means that [[Invoke]] would go away and issues like the ones Jason are concerned about would also just go away.

There can still be semantic irregularities introduce by poorly designed proxy handlers.  The answer to that seems to be "don't do it".   Proxies work well for a few specific use cases such as complete membranes. They don't work well for other use cases such as care takers over built-ins with private state.  We tried to tweak the Proxy design to make it useable for a wider variety of use cases, but more issues keep turning up.

So, it sounds to me that [[Invoke]] needs to go away.

Allen 




More information about the es-discuss mailing list