I don’t know if this has been discussed, but I find the |super| work-around
provided by YUI and CoffeeScript (in the generated code) not that bad:
ThisClass.__super__.foo.call(this, arg1, arg2);
With ThisClass.__super__ pointing to SuperClass.prototype.
As a completely static solution, one could maybe expand a super-call
super.bar(x, y);
to
__CurrentObject__.[[Prototype]].bar.call(this, x, y);
On the other hand, I don’t know if a reference to __CurrentObject__ is ever
available for some kind of static expansion.
On Jun 25, 2011, at 19:51 , Brendan Eich wrote:
> 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
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
