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.
[snip]
> 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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
