I think callingsuper inside anonymous functions inside methods can help sometimes with logic structure. So I would vote to keep existing support and not be as strict as ES2015.

I'm all for option 1. See#3796.

I personally never usedsuper outside of classes, so1 is completely fine to me.
However3 would be an understandable choice to avoid breaking changes + nicer output.

I think since this is already the big breaking change release, option#1 is the way to go.

OK, I'll go for option 1., and we can discuss about@jashkenas' comment as a separate new feature.

@mitar calling super within anonymous functions is possible, so long as they are arrow functions.

classA{method(){console.log('A#method')}}classBextendsA{constructor(){(()=>super())()}method(){(()=>super.method())()console.log('B#method')}}newB().method()// A#method// B#method

I also think we should go with option 1, since we can always add the more elaborate versions later.

This PR has a bug though I think. Take this input:

classAfoo:->console.log'woohoo!'classBextendsAbar:->super.foo()

This branch produces:

varA,B;A=classA{foo(){returnconsole.log('woohoo!');}};B=classBextendsA{bar(){returnsuper.bar(...arguments).foo();}};

but it should produce:

varA,B;A=classA{foo(){returnconsole.log('woohoo!');}};B=classBextendsA{bar(){returnsuper.foo();}};

Not a bug - that's how CoffeeScript'ssuper works. See#2638 for some discussion on this.

Interestingly, it seems thatsuper of this form used to be planned for ES:https://esdiscuss.org/topic/referencing-super. I can't find any reference to when it was dropped.

Personally, I think being able to look up arbitrary methods on the superclass is an undesirable feature. An overridden method shouldn't need to be aware thatother methods may be overridden. I.e. ifbar wants to callfoo, it should callthis.foo; ifB#bar wants tospecifically callA#foo, it should callA::foo.

It also encourages people to think thatsuper is an entity of its own, perhaps an object containing references to methods of the superclass, but it is not (in ES discussions it was proposed to meanthis, which would have meant thatsuper.foo anda = super, a.foo would target different methods!).

Not a bug - that's how CoffeeScript's super works. See#2638 for some discussion on this.

Interestingly, it seems that super of this form used to be planned for ES:https://esdiscuss.org/topic/referencing-super. I can't find any reference to when it was dropped.

Personally, I think being able to look up arbitrary methods on the superclass is an undesirable feature. An overridden method shouldn't need to be aware that other methods may be overridden. I.e. if bar wants to call foo, it should call this.foo; if B#bar wants to specifically call A#foo, it should call A::foo.

It also encourages people to think that super is an entity of its own, perhaps an object containing references to methods of the superclass, but it is not (in ES discussions it was proposed to mean this, which would have meant that super.foo and a = super, a.foo would target different methods!).

I agree with this (naturally), and I think I've made that argument in these pages before.

But! If we're switching over to ES6 semantics for classes for CS2, shouldn't we switch over to ES6 semantics for super at the same time?

Asuper.foo() like my example wasn't just planned; it's implemented. Paste my "should output" example into Chrome console to see for yourself. We need to support this type ofsuper.

Well, I'd argue that with classes we've changed very few semantics - we've adopted, by necessity, theclass {} syntax (and associated baggage 😅 ), but have avoided removing any significant CS features.

@GeoffreyBooth it's theother form that was planned not implemented (super()), sorry.

I'm not sure I agree that weneed to support it. I feel like we're just adding needless redundancy since 99%¹ of uses are justsuper.<current function>, and any other case is almost certainly a sign of bad design, or a contrived example for a test case. I wish ES Discuss was more searchable so I could figure out why they chose this approach.

Whilst maintaining that it would be best not to, we could make both uses live side-by-side. If we do go down that route we might want to talk about letting 'baresuper' go, and mandating regular function syntax (i.e.super arguments... would replace baresuper).

1. Made up.

Usingsuper to call a different method on the parent isone of the examples on MDN'ssuper page, and it doesn't seem contrived. Regardless of what we do with "bare" super, we need to support this usage too.

I think that once again, it'll be a step backwards — but we should make it work like JSsuper works. Keeping different semantics will just breed confusion when people try to use it, and will be a running source of new opened tickets asking for it to be changed.

OK, lets addsuper.method.

Next question is baresuper -super.method makes it look likesuper is something that hosts superclass versions of methods, maybe, whereas in CS it is in fact a method call and in ES it's a syntax error. Since we're adoptingsuper.method, I suggest we also adopt aSyntaxError for baresuper. This eliminates the ambiguity observed by@GeoffreyBoothabove.

To outline the suggested compilation:

classBaseclassSuperExamplesextendsBase# Should throw a SyntaxError along the lines of "'super' must be called or accessed"bareSuper:->super# Should compile to `super.shortSuper()`shortSuper:->super()# Should compile to `super.esSuper()`esSuper:->super.esSuper()

Yes, we should make it work like ESsuper — in all respects.

It looks like I was hasty to say"it's a 'syntactic form' that is only valid within a class initializer" - it seems it's also valid within methods in object initializers:

({foo(){super.foo()}// OK})({foo:function(){super.foo()}// SyntaxError: 'super' keyword unexpected here})

Of course we don't currently compile object assigns with method values to that syntax. I had planned to look into that at some point to clean up the code I had to put innodes.Code for the class work, so might investigate that.

But how are you supposed to get that "method" back onto the prototype from outside?

Man, it just keeps getting worse and worse...

Heh, I was just writing a similar example in node, and got the same result. The MDN example shows using it viaObject.setPrototypeOf.

Object.setPrototypeOf(a,Lion)newa().speak()

This works:

functionA(){}A.prototype={foo(){console.log('A#foo')}}functionB(){}B.prototype={foo(){super.foo()console.log('B#foo')}}Object.setPrototypeOf(B.prototype,A.prototype)newB().foo()// A#foo// B#foo

So, it seems thatsuper can only appear in 'initializer method literals',and can only target initializer method literals. Otherwise there's a runtime error.

Edit: It seems the methods must be within their original object as well, the following doesn't work:

A.prototype.foo=({foo(){console.log('A#foo')}}).foo...B.prototype.foo=({foo(){super.foo();console.log('B#foo')}}).fooObject.setPrototypeOf(B.prototype,A.prototype)newB().foo()// TypeError: (intermediate value).foo is not a function

This works ...

No, as you demonstrate below, there's still no way to add methods to an existing prototype and make use ofsuper. That's the "normal" ES3 ability that we're losing in ES6.

So it basically seems thatsuper is 'half-bound' at compile time. The prototype can be changed but the 'home object' (as it's referred to in the spec) cannot.

base={foo(){return'base'}}child1={foo(){returnsuper.foo()+' -> child1'}}child2={foo(){returnsuper.foo()+' -> child2'}}try{child1.foo()}catch(e){console.log(e)// TypeError: (intermediate value).foo is not a function}Object.setPrototypeOf(child1,base)console.log(child1.foo())// base -> child1Object.setPrototypeOf(child2,base)console.log(child2.foo())// base -> child2Object.setPrototypeOf(child2,child1)console.log(child2.foo())// base -> child1 -> child2method=child2.fooconsole.log(method())// base -> child1 -> child2functionA(){}A.prototype.method=child2.fooconsole.log(newA().method())// base -> child1 -> child2

OK, I've pushed some more updates that adds support forsuper with accessors! Seethis test andthe following one for some contrived examples.@GeoffreyBooth your example now indeed compiles to:

// Generated by CoffeeScript 2.0.0-alphavarA,B;A=classA{foo(){returnconsole.log('woohoo!');}};B=classBextendsA{bar(){returnsuper.foo();}};

I've also fixed a couple of incidental bugs that were exposed by these changes, including:

1. Soakedsuper invocations. There was existing code inCall to deal with soakedsuper invocations, but as far as I can tell the parse tree would never actually evaluate to a soaked call due to baresuper taking precedence (i.e.super?() was interpreted assuper()?()).

2. Generating bound functions for the closures that wrap statement expressions when the expression containssuper. This also meanssuper can now be used in constructors withintry expressions, etc. There is an edge case for statement expressions containing bothsuper andyield, because bound functions cannot be generators (i.e.try (super; yield)).

3. Special-case handling to supportclass @A extends A when compiled as a simple class. There was a test for this that started breaking once classes with parents no longer needed an IIFE wrapper. To comply with the tests, some extra handling was put in place to wrap the class in an IIFE if the parent's name matches the class' name. I wouldn't be opposed to dropping this, as it seems like it would be an unusual case, and the workaround is pretty awkward.

   Edit: Looks like this test was addedhere to fix an infinite recursion bug. The error now would be a (still surprising)ReferenceError: A is not defined, because the secondA refers to the not yet defined class. Any thoughts@jashkenas ?

4. Throw a compile error when callingsuper withnew. Previously, thenew would simply not be emitted! From my experiments it seemssuper withnew is syntactically valid JS, but it always fails at runtime with "unsupported 'super' reference", so I've made it a compile error.

Awesome work! Assuming all the tests pass, is there anything else to be done forsuper?

Aside from adding support forstatic,get andset, is there anything else to be done for classes?

@GeoffreyBooth I think we need to have a discussion aboutstatic. CS already supportsstatic with@name [:=] assignments, which is far more idiomatic within the language (no special syntax). From a JS dev perspective it's also a straightforward conversion (static =>this).

Regardingsuper, I need to review some of the newclass tests. At least one of them was testing thatsuper intry blocks won't work, except I believe they should now, yet the test is still passing.

We can discussstatic,get andset in another thread. What I'm wondering is when the2 branch is ready for release as the first alpha. It sounds like as soon as you're done checking these tests and perhaps fixing some issues, we're good to release?

@GeoffreyBooth I think we need to have a discussion about static. CS already supports static with@name [:=] assignments, which is far more idiomatic within the language (no special syntax).

I'd love to keep this sort of thing, and avoid the wordstatic if possible. I think it's a terrible word for the feature, and is just legacy baggage from Java.

@GeoffreyBooth I think that would be sufficient, yeh. I'll review those tests asap and double check there's nothing else we can throw out.

Also if@lydell or@jashkenas (or anyone with more familiarity with the grammar) have any comments on thegrammar changes they'd be very welcome.

@lydell did you have any further notes on this or is it ready to merge?

I'll aim to address those last comments and review the class super tests this evening.

@connec along with making the changes discussed recently, can you please updatehttps://github.com/jashkenas/coffeescript/wiki/%5BWIP%5D-Breaking-changes-in-CoffeeScript-2? Once the info about breaking changes for classes is in there, I think I'll move it into the docs proper.

@GeoffreyBooth /@lydell I've responded to the review issues. I've left some additional TODOs for the class tests that were added in#4354, rather than trying to tackle them in this PR (all the tests pass, but some should now 'fail' that were testing for broken things that now work...).

In short, I think this is ready to go.

Good job,@connec!