Re: [[Invoke]] and implicit method calls, once more
To confirm what Allen already mentioned: I too concluded from the discussion that we would remove [[Invoke]] from ES6. It is one of a few items I would like to put on the agenda of the TC39 November meeting to get a definitive consensus (the other item being the removal of the hasOwn() trap, for which there also was consensus on the list). Regards, Tom 2013/10/18 Allen Wirfs-Brock al...@wirfs-brock.com On Oct 18, 2013, at 11:06 AM, Brandon Benvie wrote: On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote: 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. Isn't there observably different behavior different depending on whether invoke exists or not? Even if you don't implement it in your handler? If that's the case, then it's not guaranteed that it can be added later down the line. Yes, and those differences are not easily fixable in the context of the current Proxy design. As currently defined, some possible uses of Proxies will be broken regardless of whether or not [[Invoke]] is there. Yet, the only reason to add [[Invoke]] at this time would be to try to fix issues with Proxies but even with [[Invoke]] we still have issues. And. for ES6, we're run of time for experimenting with fixes. However, as Mark pointed out, experts can make them work for specific use cases and they are essential for supporting membranes. So we can live with the exiting design (without [[Invoke]]) as an expert feature for building membranes and similar use cases. If we ever come up with a better design (perhaps including [[Invoke]]) we can always introduce a new kind of proxy that works with it. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls, once more
2013/10/18 Till Schneidereit t...@tillschneidereit.net I share this concern. Last time we discussed it, Brendan said that we could implement it by falling back to .get if .invoke isn't defined[1]. I'm not sure how well that fits into the rest of the Proxy design, though. It doesn't fit the direct proxies design (which wants to forward to the target by default for missing traps), but it does fit the old proxy design (where the proxy would indeed fall back to more primitive traps if more specialized traps were missing). There is a case to be made for switching designs for backwards-compat reasons. It would be symmetry breaking but it would give us the necessary leeway to evolve the API. Worst-case, as Allen mentioned, we can introduce a distinct proxy constructor. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
[[Invoke]] and implicit method calls, once more
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. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls, once more
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls, once more
On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote: 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. Isn't there observably different behavior different depending on whether invoke exists or not? Even if you don't implement it in your handler? If that's the case, then it's not guaranteed that it can be added later down the line. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls, once more
On Fri, Oct 18, 2013 at 8:06 PM, Brandon Benvie bben...@mozilla.com wrote: On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote: 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. Isn't there observably different behavior different depending on whether invoke exists or not? Even if you don't implement it in your handler? If that's the case, then it's not guaranteed that it can be added later down the line. I share this concern. Last time we discussed it, Brendan said that we could implement it by falling back to .get if .invoke isn't defined[1]. I'm not sure how well that fits into the rest of the Proxy design, though. [1]: https://mail.mozilla.org/pipermail/es-discuss/2013-September/033610.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls, once more
On Oct 18, 2013, at 11:06 AM, Brandon Benvie wrote: On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote: 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. Isn't there observably different behavior different depending on whether invoke exists or not? Even if you don't implement it in your handler? If that's the case, then it's not guaranteed that it can be added later down the line. Yes, and those differences are not easily fixable in the context of the current Proxy design. As currently defined, some possible uses of Proxies will be broken regardless of whether or not [[Invoke]] is there. Yet, the only reason to add [[Invoke]] at this time would be to try to fix issues with Proxies but even with [[Invoke]] we still have issues. And. for ES6, we're run of time for experimenting with fixes. However, as Mark pointed out, experts can make them work for specific use cases and they are essential for supporting membranes. So we can live with the exiting design (without [[Invoke]]) as an expert feature for building membranes and similar use cases. If we ever come up with a better design (perhaps including [[Invoke]]) we can always introduce a new kind of proxy that works with it. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
