brendan at mozilla.com
Tue Nov 1 10:30:15 PDT 2011
On Nov 1, 2011, at 9:45 AM, Allen Wirfs-Brock wrote:
> The complication of super is that each "super call" requires two independent pieces of state in additional to the method arguments: the object that will be used as the |this| value of the resulting method invocation and the object where property lookup will begin when searching for the method. Let's call this the "lookup-point". |super| when used to access a method property really represents a pair of values (this,lookup-point). In the general case, these are not the same value so they must be independently captured and represented.
> Just saying "I don't think that an efficient, pay-as-you-go dynamic super() will be easy, but with the technical chops of TC39 at your disposal, it should be possible" is not helpful, particular when you make other statement that suggest that you really don't understand all the semantic subtitles of super. I hate to cite "authority" but the semantics and implementation alternatives of super has been thoroughly explored over 30+ years by object-oriented language designer and implementer including myself. This is not a new problem, the "technical chops" have already been supplied. A unique new solution that no one has ever though of before would be welcomed. If you have such a solution, please put it forward. But don't assume that it is something that has not already been deeperly consider both by TC39 member and other language designers.
There can't be a solution if the problem is as stated. We have a pigeon-hole problem with only one implicit ("0th") parameter |this|, but two actuals that must be (in general) passed: (this, lookupPoint).
The solution (b) puts lookupPoint in the [[Super]] internal property of the method's function object, where it can be fetched, and which can be preset for a copy of the function object via Object.defineMethod. Any solution that puts lookupPoint somewhere in the heap reachable from the method is equivalent.
Storing lookupPoint in |this| doesn't work -- pigeon-hole problem again (may have several super calls nesting on the same |this|).
No more time for a formal proof, but it seems to me this is enough. Plan (a) is right out -- no implementor and few users will go for such an increase in argument passing overhead. Plan (b) wins.
More information about the es-discuss