constructor renaming parameters

[crisward]

If you do this

class Blah
  constructor:(@thing)->
     @thing()
      
  method:->
    thing = "hi"

Coffeescript compiles to

var Blah;

Blah = class Blah {
  constructor(thing1) {
    this.thing = thing1;
    this.thing();
  }

  method() {
    var thing;
    return thing = "hi";
  }

};

Why the 1 after the thing?? I'm using an dependency injection system, and the rename is playing havoc with it. Coffeescript 1 didn't do this.

[vendethiel]

Coffeescript 1 didn't do this.

It's been doing this since 1.9.0, 29jan 2015.

[crisward]

Is there any documentation or issue as to why coffeescript does this? I can understand why it may be necessary if the variable is declared outside the class, but inside the function doesn't seem to make any sense.

[lydell]

@crisward Why does it matter to you what a generated variable name looks like? Could you show an example?

[vendethiel]

8ab15d7

@lydell probably the DI system looks up the name of the parameter to inject. I know AngularJS1 did that.

[crisward]

We use a dependency injection system which parses the output of the constructor to know what modules to inject (a bit like Angularjs did). This can't find a module with a 1 at the end.

[crisward]

Just checked and coffeescript 1.9.1 didn't do this.

[lydell]

Just search for “angular” in this issue tracker and you’ll find everything you need.

[vendethiel]

➜  coffeescript git:(533ad8a) ./bin/coffee -bce '(@a) -> a'
// Generated by CoffeeScript 1.9.1
(function(a1) {
  this.a = a1;
  return a;
});
➜  coffeescript git:(533ad8a) ./bin/coffee -v
CoffeeScript version 1.9.1

CoffeeScript 1.9.1 did do that.

[vendethiel]

Also, how does your DI deal with minified code? I know that was an issue in AngularJS and that's why people ultimately stopped doing it (... or developed modules to do it automatically).

[crisward]

It's node, so doesn't need to be minified. Also you can just not mangle in uglify for client side stuff.

I have a codebase I'm converting from 1.9.1 to 2.* and it's breaking in lots of places. So there is a difference somewhere. I'll take a look around the issues and see if I can get a work around. The other option I have is to avoid using a lib name in my code, just seems a bit unnecessary.

BTW thanks for the rapid response.

[vendethiel]

Just to be clear: if you write (@a) -> @a, then the compiler doesn't have to reserve a, and names the parameter a. I would recommend against depending on this, but it should solve your outstanding issue.

[lydell]

@vendethiel That is super fragile though becase if you name a variable a anywhere else in the same file (even if not in the same method) the generated variable will become a1.

[crisward]

@vendethiel thanks for the help, I looked at some of the other issues. I'm injecting @request, and using the variable name request in a method, which causes @request to become @Request1.

I think the simplest solution as I'm migrating old code is just to add an alias to my injector for generic library names to be added with the additional '1' on the end. Request is the main one as it's a commonly used variable name in node code.

Thanks.