Implement super

[mizchi]

It works in most cases but with memberAccessOp doesn't.
I can't guess some specs. So I want to ask here.

[vendethiel]

oh :).

[mizchi]

I want to catch member assigment of class from here but how can I decide its order?

[akre54]

Excellent!

[mizchi]

Fix by myself :) but I have no confidence it is correct way... in especially assignee detection.

@michaelficarra please give me advice, or merge if you don't care.

[akre54]

You could probably do call for > 0 args, falling back to apply for 0 args

[mizchi]

I checked jashkenas/coffeescript now.

    Sub.prototype.func = function() {
      Sub.__super__.func.apply(this, arguments);
      Sub.__super__.func.call(this, 3);
      return Sub.__super__.func.call(this, 3, 5);
    };

Yes, you are right. I'll fix.

[akre54]

There are still a few pending tests that could get squashed by this. The static super ref needs to reference __super__.constructor (CS), and some of the scope lookup stuff may need some streamlining. But awesome to get the main case out of the way on this!

[mizchi]

I will implement static super too. After that I want to reply other peoples fix.

[michaelficarra]

Shouldn't this be in primaryExpression? super.a should be allowed. Though it would introduce ambiguity with super a, it should still parse fine.

[michaelficarra]

Thanks for the PR, but there's a lot of work still needed here and, more importantly, I am still not sure of the future of super in CoffeeScript to begin with. Many, including myself, have been petitioning the other maintainers for adoption of ES6 semantics.

[akre54]

Shouldn't CSR at least try to match CS super as it stands now, and then fix if CS changes? There hasn't been any progress on super in years and it's preventing many people (myself included) from switching to CSR.

[michaelficarra]

Sure. I'd merge a PR that achieves that. We need all those tests I mentioned in place first, though.

[mizchi]

My private goal is that I want to make CSR which has compatibility to CS. (And for my hobby project TypedCoffeeScript that aimed to super set of CS, but you, execept me, don't have to take care about it:)

Anyway, I will fix some point you mentioned first. Thx!

[mizchi]

I tried but I didn't know generating class$ without var name confliction. Need to change on cscodegen?

[michaelficarra]

No, cscodegen is for generating CoffeeScript source code from a CoffeeScriptRedux AST (and is woefully incomplete). Can you explain the problem in more detail?

[mizchi]

Now it works about super and static method super in class as CS specs.

[michaelficarra]

Please copy these lines to the callExpressionNoImplicitObjectCall definition. That rule is used in places where a call is not allowed to be passed an implicit object, such as the B C call in

class A extends B C
  constructor: ->

Then include a test for a super call in that position.

[mizchi]

Oops, I passed only syntax and broke execution. I'll fix...

[mizchi]

I failed it yet.

[notslang]

+1 thanks @mizchi, this is a hugely important for me being able to move to CS-redux

[ef4]

I incorporated this PR into my ES6 branch, so I can piggyback off the super keyword. It's working pretty well. Demo:

$ cat sample.coffee

class Foo extends Bar
  someValue: 1
  constructor: (a) ->
    super(a)
  doIt: ->
    super("yay")

$ ./bin/coffee --bare --js --input ./sample.coffee --target-es6

// Generated by CoffeeScript 2.0.0-beta9-dev-es6
class Foo extends Bar {
  constructor(a) {
    super(a);
  }
  doIt() {
    return super.doIt('yay');
  }
}
Foo.prototype.someValue = 1;