You can clone with
HTTPS or Subversion.
super a, b, c
I’m in favour of ES6-way which will be consistent with futurejs.
So, super should just be a ref to superclass. This will also allow to use it in static methods etc which will close gh-1790
I'm afraid we're not targeting ES6 yet -- and at the time that CoffeeScript's super was defined, ES6's semantics weren't yet nailed down. I'm still not sure if their super is going to change before it begins to appear in browsers.
More importantly than that, I think our semantics are desirable. I think that languages that allow you to write:
super.otherMethod(1, 2, 3)
... are violating encapsulation. Your method implementation shouldn't have to know where in the inheritance hierarchy you need to call. super should only ever be an implementation detail of the current method. In addition, if you really need to apply a method from another object against this -- you can always do that manually with call and apply
actually I agree with jash’s args, almost never called other superclass methods in apps. But almost always calling super (without args and stuff).
what about allowing super:: ?
Seems overly ugly to me, doesn't it?
Just name the external class -- like you usually would.
I suppose that's the best way
One of the problems of implicit delegation: Default values for parameters don't work. I guess this could be fixed in Redux.
ECMAScript 6 & Coco & LiveScript: super is just a direct reference to the super function.
Would be great if this were true. In reality it isn't that simple due to the implicit .call(this).
I don't know if it helps with CoffeeScripts eventual push to incorporate ES6 features once it's ratified (later this year?), but it seems CoffeeScript's super wouldn't need a change at all (at best minor):