Making "super" work outside a literal?
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.
Not sure what can be done about this.
More information about the es-discuss