rainforestapp / decaf

Coffeescript to ES.next transpiler. Now maintained over at
https://github.com/juliankrispel/decaf
MIT License
106 stars 10 forks source link

coffeescript classes and es6/babel classes aren't compatible #127

Closed juliankrispel closed 8 years ago

juliankrispel commented 8 years ago

cc @eventualbuddha

Right. So at rainforest we have a legacy coffeescript/backbone codebase (which I'm trying to rid ourselves of). I've observed two problems that are a major PITA, in regards to classes.

Problem 1: Es6 inheritance doesn't include static members but CS inheritance does

Given the example

class A

A.b = [1,2,3]

class B extends A

console.log(B.b) // yields [1,2,3]

The above works in coffeescript because of the extend helper function in coffeescript. It copies the prototype as well as any static members of the class.

However in es6, class inheritance doesn't include static members. This means only the prototype is copied.

Problem 2: In Coffeescript, static class properties are mounted before the constructor is called, in es6 it's the other way around.

Given the example

function A(){
  console.log(this.routes); // yields undefined
}

class B extends A {
  routes = ['dwq', 'dwq']
}

new B({routes: [1,2,3]});

the static attribute routes will actually not be mounted when constructor A() is executed.

@eventualbuddha any ideas how to solve these two? Or maybe you've already addressed these?

eventualbuddha commented 8 years ago

For problem 1, I don't think that's actually an issue. This example works the same way as the CoffeeScript one:

class A {
  static b = [1, 2, 3]
}

class B extends A {}

console.log(B.b);

For problem 2, the routes = … part becomes something like this in a constructor: this.routes = …, but that has to happen after the implicit super() call. So it works in CoffeeScript because the routes = … becomes part of the prototype rather than a constructor assignment. I haven't done anything to address this 😞 I tend to favor the idiomatic approach over the exactly compatible one. ¯(ツ)

juliankrispel commented 8 years ago

@eventualbuddha number 2 is another candidate for an error I think

lemonmade commented 8 years ago

2 should probably be an error, assigning to the prototype does not have the same semantics as assigning to each instance (in the CoffeeScript case, the value is shared between all instances of the class, whereas instance class properties are set individually for each instance).

juliankrispel commented 8 years ago

also fixed by

juliankrispel commented 8 years ago

fixed in #144