Making "super" work outside a literal?

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Sat Jun 25 14:37:43 PDT 2011


On 26.06.2011 1:06, Brendan Eich wrote:
> On Jun 25, 2011, at 2:01 PM, Dmitry A. Soshnikov wrote:
>
>> On 26.06.2011 0:49, Brendan Eich wrote:
>>> On Jun 25, 2011, at 11:13 AM, Axel Rauschmayer wrote:
>>>
>>>> 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);
>>> I'm not sure what you mean. If we add 'super', surely we want more than the __super__ hack. We also want a callable expression 'super' in constructors, and a 'super.foo' form for method and other property accesses from subclass methods. We don't want people writing out .call by hand.
>>>
>>>
>> Apologize in advance if I'm mentioning already discussed thing in these classes-related topics (unfortunately hadn't enough of time to read them all and follow), but from what I can say, people want to write also and _mostly_ _just_ `super`, not even `super.foo` (though, of course `super.foo` notation would be also nice to have -- to be able to call _any_ parent method).
> In a constructor, calling super calls the super-constructor. No need for super.constructor() or whatever.
>
Yeah, and constructor is just another method, the same as others; it 
just initializes the instance. Why from this viewpoint not to allow the 
user to call a parent method with the same name from another method, 
e.g. `foo`?

> Unlike CoffeeScript, which allows a method foo to super-call only the method of the same name in the superclass, the ES.next proposals I've seen want super.foo(). This allows super.bar() from method foo of a subclass, where the superclass bar might of course loop around and call the superclass foo.
>

Yes, I understand and also noticed that it's a good _addition_ -- to be 
able call _any_ parent method from another method (e.g. `super.bar` from 
`foo`). Moreover, this strategy is used in many other languages.

E.g. PHP also uses "full notation" everywhere, even for `__construct` -- 
you should call `parent::__construct(...)` as well as `parent::bar(...)` 
from `foo` (though, I don't program PHP already long time, probably 
something have changed in this respect).

Python e.g. also forces you to write the same method name when calling 
parent method: either `super(BarClass, self).__init__(...)` or with 
hardcoding parent class-name: FooClass.__init__(...). The same for all 
other methods.

It's completely OK and again, the ability to call any parent method is 
just fine. But Ruby's/Coffee's/Java's/<OtherLang>'s super-only, that is:

foo: function(x) {
   super(x) + x
}

seems a good sugar vs:

foo: function(x) {
   super.foo(x) + x
}

Is there _any_ reason why I should repeat this `foo` name in respect of 
a good code reuse?

_Of course_, if I need to call `bar` method, then super.bar(...) is just 
the perfect addition and CoffeeScript lacks of it.

>> Again, we even _now_ (vis simple JS class-library) can write normal `this.super(...)` calls from _any_ descendant method (and could even in ES3 era, though, via `this._super(...)`) -- that is without specifying exact parent name (i.e. `super.foo`) which in case of the same method is just again is the syntactic noise. So it's important thing to have _just_ super(...) -- if it's a sugar, let it be really the sugar (because if not, why do I need it at all if I can achieve even better with a library?). And _in addition_ -- super.otherMethodName notation.
> For some reason I missed this Ruby-ish notion of super-method calling, which CoffeeScript supports. It is not what the ES.next proposals require for a super-method call. See
>
> http://wiki.ecmascript.org/doku.php?id=harmony:classes#member_delegation
>

Yep, thanks I'll check it in detail.

> We should discuss this more concise 'super'-only, not 'super.foo' idea. Is it only for conciseness, or is the fact that it does not support 'super.bar' from within a method named 'foo' important?
>

Of course it's mostly for conciseness. And I propose to implement both 
-- just `super` and `super.foo`. I think the percentage when people use 
the same name parent method vs. another parent methods is something 90% 
- 10%. So to repeat every time the same parent name in this 90% of case 
is a noise IMO. But in later 10% to be able to do this is a very good 
addition for the language.

P.S.:

In a simple JS-library, once again, it's not a problem to have both 
today: this.super(...) and this.super('bar', ...). Using proxy I think 
it's possible even to achieve this.super.bar(...) or even super.bar(...) 
in SpiderMonkey where global object inherits from Object.prototype, but 
these are just experiments. Though, this experiments shows that the 
sugar can be achieved w/o internal implementation, but of course with 
built-in implementation it will be much faster. The only thing I want if 
it's a sugar, let give the users exactly the sugar, that is: `super(x) + 
x` in 90% of cases.

P.S.:[1] 90% vs. 10% is of course a rough own-experience valuation.


Dmitry.



More information about the es-discuss mailing list