Making "super" work outside a literal?

Brendan Eich brendan at mozilla.com
Sat Jun 25 10:51:29 PDT 2011


On Jun 25, 2011, at 10:31 AM, Allen Wirfs-Brock wrote:

> On Jun 25, 2011, at 6:10 PM, Brendan Eich wrote:
> 
>> On Jun 24, 2011, at 1:00 PM, Allen Wirfs-Brock wrote:
>> 
>>> If there was a mechanism for lexically addressing this, I would expect |super| to track |this| in parallel.  From a value perspective, |super| is just a synonym for |this|.
>> 
>> This is an important point, although what is a non-value perspective in JS?
> 
> Perhaps I should have said binding perspective.

"binding" is a much abused word, but in JS communities I hope we can keep it restricted to names in environments, lexical vs. dynamic vs. argument value to formal parameter binding -- at most!

But I get what you mean. 'super' by itself is a reference to the same object 'this' denotes, or undefined where 'this' is undefined. 'super' and 'this' are aliases. But 'super'-based property references start from a different prototype chain head.


>> There are no explicit types. The answer must be an implicit type, the superclass view provided by the [[Prototype]] of the class prototype or ad-hoc containing object in which the method using 'super' was written.
> 
> What you are concerned about here may be too subtle for some readers.  Any caching of a |super| based property lookup needs to be keyed by the internal type of the object where the property lookup actually starts rather than the internal type of |this|.

Yes, I'm concerned about subtlety if 'super' in functions. The tension is between confining 'super' to be valid only in class methods, vs. making it work in any function. But the class-methods-only approach leads to invoke-only methods, to avoid the reparenting or borrowing problem that Object.defineMethod addresses.

I'm less concerned about 'super' for all functions, plus Object.defineMethod. This is "JavaScript-y" and causes me less concern than a class-based 'super' confinement attempt. But the whole package deal still causes concern, because of the "you forgot to use Object.defineMethod" problem. We're adding another runtime error case, a hazard requiring test coverage.

Not sure what can be done about this.

/be


More information about the es-discuss mailing list