Allow captured `this` in a class

[nycdotnet]

It's common for JavaScript code to capture this to a variable like self or that. One of the pain points when converting existing JavaScript functional-style "class" code to an idiomatic TypeScript class is the required chore of going through the file and replacing any instance of a captured this variable with an ambiguous this, likely breaking code that was already working; then, doing a second pass to figure out which functions need to be converted to lambdas to hopefully unbreak the code. This chore is tedious, error prone, and offers no business value; in fact it has a negative value at first. It's also a "day 1 sledgehammer" - the very people who are most likely to need to do this type of work are JavaScript developers giving TypeScript a try.

I think there's a very straight-forward solution for this: it should be legal to capture this at the top of a TypeScript class. For example:

class MyClass {
  var that = this;
  public name: string;
  public sayHello() {
    console.log(that.name);
  }
}

proposed emit:

var MyClass = (function () {
    function MyClass() {
        var that = this;
        this.sayHello = function () {
            console.log(that.name);
        };
    }
    return MyClass;
})();

The emit would work identically to how the automatic var _this = this; works when lambdas are used in a class. In the example above, that would be of type MyClass. I don't believe that it would be required to support this proposal in a defintion file except perhaps when typeof is used, in which case the name of the class could be substituted for the typeof expression. Multiple variables could plausibly be assigned to this, but it would remain illegal to declare variables in the class scope unless they are immediately assigned to this; the emit would have to be at the top of the function, above member definitions (same place as var _this = this; already is).

Having this feature would save a tremendous amount of busywork when converting large classes from JavaScript to TypeScript. I know there are a bunch of other this proposals out there, but I read through #513 and it didn't seem to have this particular idea.

Thanks very much for your efforts with TypeScript - it's such a great language to work with. I appreciate your consideration of this proposal.

[RyanCavanaugh]

Can you post an example of how this would be emitted?

[nycdotnet]

Done. Thanks, Ryan.

[mwisnicki]

Why limit assignments to this ?

[nycdotnet]

Why limit assignments to this ?

Limiting assignments to this prevents people from writing ambient code. Code in a class should be inside functions or on declarations only. If ambient code is desired, use of a module is more appropriate. At least, that was my thinking for this proposal and I think this is how TypeScript is currently designed.

[basarat]

Based on the proposed emit, it seems that perhaps these people should really just convert original code to lambda's to begin with, i.e.:

class MyClass { 
  public name: string;
  public sayHello = () => {
    console.log(this.name);
  }
}

This way :

• There is no new syntax
• They don't need to rename this to that

Alternatively this already works, but does have an ugly this.that:

class MyClass { 
  public that: MyClass = this;
  public name: string;
  public sayHello(){
    console.log(this.that.name);
  }
}

[nycdotnet]

Hey @basarat,

For this proposal, I purposefully selected an emit style to mirror the emit used with lambdas because it's a JavaScript style that the TypeScript team is already comfortable with (hopefully, because they chose it).

There is no problem with converting a two member class to use lambdas. This proposal is intended to assist people with many large/complex function-style "classes" with many members. It's far too difficult currently to do all of the refactoring required to take advantage of proper TypeScript classes. Choosing to do so requires people to risk breaking code that is already working correctly - particularly if you start getting into situations with nested callbacks. Saying "just rewrite it" doesn't fly because there's no obvious benefit.

I'm almost done with my Pluralsight video and it should hopefully be out in a few weeks. Probably a good 10 minutes in the course is spent fighting with converting a big JS function-style "class" to TypeScript just messing around with this and rewriting stuff as lambdas. I wouldn't mind if it were new code, but this was code that was already working and this was settled (as self). By converting it to use this, I broke it. It took two or three tries to get it right again after doing find and replaces, etc. If someone came to me and asked "Was all that time you just spent rewriting that function as a class worth it?" I would have a hard time saying that it was - at least not immediately. It used to be clear at a glance when we meant the class and when we meant the contextual this due to the variable name. After the "improvement" to using a proper class, we have to look at what style of function we're in to figure it out. While I think ultimately there could be a benefit, for large function-style classes it's almost best to leave them alone today and just write an interface.

With this small feature, that whole battle goes away and dealing with this in an already-working function that you're converting to a class takes all of 5 seconds. Your team can keep the capture variable they've grown accustomed to. To me, there's just so many practical benefits.

[basarat]

Saying "just rewrite it" doesn't fly because there's no obvious benefit.

Got it. So you basically want to make it easier to change the codegen to that (with ()=> semantics) without forcing them to rewrite it. Sorry I took some time to understand ❤️

With this small feature, that whole battle goes away and dealing with this in an already-working function that you're converting to a class takes all of 5 seconds

Was the old code using the revealing module pattern?

[nycdotnet]

The original code in my case was using the style demonstrated in the Knockout tutorials. For example, http://learn.knockoutjs.com/#/?tutorial=loadingsaving

[RyanCavanaugh]

Upon closer inspection, this behavior is far too subtle -- using the var here in sayHello changes it from a prototype member to an instance function. That has a ton of implications that are not immediately obvious, and it does need to be apparent from looking at a member whether it's instance or prototype.

Ideally editors would be able to provide a refactoring here to ease the JS transition path.