Make "this" the default context inside classes

Topics: General
Jan 11, 2013 at 8:55 PM

Why not have a default context of "this" inside instance methods, like C#?

Seems to me it would be easy enough to allow this while still making "call(x, y, z)" render as "this.call(this.x, this.y, this.z)".

Coordinator
Jan 11, 2013 at 11:42 PM

There have been a few feature requests around this. 

The short answer is that, while this aspect is no doubt a little verbose, our class syntax tries to align very closely with the ES6 proposal for classes, which currently requires explicit "this." for member accesses. 

Developer
Jan 12, 2013 at 4:29 PM

Also, a real problem is that an implicit 'this' would in some cases change the meaning of the code. For example:

var x = 10;
class Foo {
    x = 20;
    f() {
        console.log(x);
    }
}
var foo = new Foo();
foo.f();

In ES6 this is supposed to output '10', but it would output '20' with an implicit 'this'. We would basically break perfectly valid ES6 code!

Anders

Jan 12, 2013 at 6:07 PM
I get this but for people like me that only does TS programming (and C#), this wouldn’t matter, I would love to have a switch in the compiler that would enable ‘implicit this”.
Another related issue is the lack of nested block scope as in C#, it's somewhat frustrating that you cannot use blocks to introduce new variable like below, any chance support for this could be added as a switch to the compiler?
{
From: ahejlsberg
Sent: ‎January‎ ‎12‎, ‎2013 ‎9‎:‎30‎ ‎AM
To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: ahejlsberg

Also, a real problem is that an implicit 'this' would in some cases change the meaning of the code. For example:

var x = 10;
class Foo {
    x = 20;
    f() {
        console.log(x);
    }
}
var foo = new Foo();
foo.f();

In ES6 this is supposed to output '10', but it would output '20' with an implicit 'this'. We would basically break perfectly valid ES6 code!

Anders

Jan 12, 2013 at 6:10 PM
Sorry I’m not really used to the new Mail app in W8...
I was adding the sample code below when Mail “decided” it was time to send the message.
{
{
var x = new Foo();
}
{
var x = new Bar(); // x is not redefined, i.e. declared as of type Foo;
}
From: ahejlsberg
Sent: ‎January‎ ‎12‎, ‎2013 ‎9‎:‎30‎ ‎AM
To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: ahejlsberg

Also, a real problem is that an implicit 'this' would in some cases change the meaning of the code. For example:

var x = 10;
class Foo {
    x = 20;
    f() {
        console.log(x);
    }
}
var foo = new Foo();
foo.f();

In ES6 this is supposed to output '10', but it would output '20' with an implicit 'this'. We would basically break perfectly valid ES6 code!

Anders

Jan 12, 2013 at 10:41 PM

Anders,

The issue you mentioned seems to be solved by the same context rules already applied today even in javascript. If there is a local variable defined, you use that, otherwise use the one from the parent closure. In the end, the compiler would follow exactly the same rules that are applied to C# compiler.

The only issue I see is that if you want to access the global variable instead of the instance one. C# has qualified names for everything, JS doesn't. But this seems to be simple to solve by not creating a local or instance variable with the same name of a global one that you want to use. Optionally, there could be a "global::x" that would look for a defined global outside of the scope and compile without the "this".

I really believe this would make coding much better than using "this" for everything.

jonturner,

I understand the will to make TypeScript compatible with current ES and ES6, but I don't believe that all TypeScript is supposed to be is a bridge between today and tomorrow. Otherwise, when ES6 is available in all browsers, there will be no reason to use TS other than type checks. As Bjorn said, this could be a switch in the compiler, or an option similar to "use strict". I really hope you don't plan for TS to be only a temporary ES6.

Jan 13, 2013 at 2:11 PM

First people ask to skip 'this.' then they ask to mandate underscore or m_ prefixes for the same.

Jan 13, 2013 at 2:20 PM
ES6 is still a dynamic language, there are no proposals to add static typing or type-checking in JavaScript, and that is the goodness that TypeScript is bringing. When the time comes that targeting ES6 is viable and the TypeScript compiler simply passes over the class declarations, there will still be plenty of other things for it to do.


On Sat, Jan 12, 2013 at 11:41 PM, nvivo <notifications@codeplex.com> wrote:

From: nvivo

Anders,

The issue you mentioned seems to be solved by the same context rules already applied today even in javascript. If there is a local variable defined, you use that, otherwise use the one from the parent closure. In the end, the compiler would follow exactly the same rules that are applied to C# compiler.

The only issue I see is that if you want to access the global variable instead of the instance one. C# has qualified names for everything, JS doesn't. But this seems to be simple to solve by not creating a local or instance variable with the same name of a global one that you want to use. Optionally, there could be a "global::x" that would look for a defined global outside of the scope and compile without the "this".

I really believe this would make coding much better than using "this" for everything.

jonturner,

I understand the will to make TypeScript compatible with current ES and ES6, but I don't believe that all TypeScript is supposed to be is a bridge between today and tomorrow. Otherwise, when ES6 is available in all browsers, there will be no reason to use TS other than type checks. As Bjorn said, this could be a switch in the compiler, or an option similar to "use strict". I really hope you don't plan for TS to be only a temporary ES6.

Read the full discussion online.

To add a post to this discussion, reply to this email (typescript@discussions.codeplex.com)

To start a new discussion for this project, email typescript@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Jan 13, 2013 at 2:20 PM
How many compiler switches do you want!?


On Sat, Jan 12, 2013 at 7:07 PM, BjornBacklund <notifications@codeplex.com> wrote:

From: BjornBacklund

I get this but for people like me that only does TS programming (and C#), this wouldn’t matter, I would love to have a switch in the compiler that would enable ‘implicit this”.
Another related issue is the lack of nested block scope as in C#, it's somewhat frustrating that you cannot use blocks to introduce new variable like below, any chance support for this could be added as a switch to the compiler?
{
From: ahejlsberg
Sent: January 12, 2013 9:30 AM
To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: ahejlsberg

Also, a real problem is that an implicit 'this' would in some cases change the meaning of the code. For example:

var x = 10;
class Foo {
    x = 20;
    f() {
        console.log(x);
    }
}
var foo = new Foo();
foo.f();

In ES6 this is supposed to output '10', but it would output '20' with an implicit 'this'. We would basically break perfectly valid ES6 code!

Anders

Read the full discussion online.

To add a post to this discussion, reply to this email (typescript@discussions.codeplex.com)

To start a new discussion for this project, email typescript@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Jan 13, 2013 at 3:32 PM
One switch to turn TS more into C# would be sufficient 😊
Honestly, I’m working on a larger project with TS for the UI and C# for the backend and it would be great to be able to use the same style of programming in both worlds. TS is so much better than JS but it could be made even better if the “ES6 alignment goal” would be dropped (or overridden by aforementioned switch)
---bjorn
From: markrendle
Sent: ‎January‎ ‎13‎, ‎2013 ‎7‎:‎21‎ ‎AM
To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: markrendle

How many compiler switches do you want!?


On Sat, Jan 12, 2013 at 7:07 PM, BjornBacklund <notifications@codeplex.com> wrote:

From: BjornBacklund

I get this but for people like me that only does TS programming (and C#), this wouldn’t matter, I would love to have a switch in the compiler that would enable ‘implicit this”.
Another related issue is the lack of nested block scope as in C#, it's somewhat frustrating that you cannot use blocks to introduce new variable like below, any chance support for this could be added as a switch to the compiler?
{
From: ahejlsberg
Sent: January 12, 2013 9:30 AM
To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: ahejlsberg

Also, a real problem is that an implicit 'this' would in some cases change the meaning of the code. For example:

var x = 10;
class Foo {
    x = 20;
    f() {
        console.log(x);
    }
}
var foo = new Foo();
foo.f();

In ES6 this is supposed to output '10', but it would output '20' with an implicit 'this'. We would basically break perfectly valid ES6 code!

Anders

Read the full discussion online.

To add a post to this discussion, reply to this email (typescript@discussions.codeplex.com)

To start a new discussion for this project, email typescript@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Jan 13, 2013 at 5:00 PM
Maybe you should look at Script# https://github.com/nikhilk/scriptsharp ?


On Sun, Jan 13, 2013 at 4:32 PM, BjornBacklund <notifications@codeplex.com> wrote:

From: BjornBacklund

One switch to turn TS more into C# would be sufficient 😊
Honestly, I’m working on a larger project with TS for the UI and C# for the backend and it would be great to be able to use the same style of programming in both worlds. TS is so much better than JS but it could be made even better if the “ES6 alignment goal” would be dropped (or overridden by aforementioned switch)
---bjorn
From: markrendle
Sent: ‎January‎ ‎13‎, ‎2013 ‎7‎:‎21‎ ‎AM

To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: markrendle

How many compiler switches do you want!?


On Sat, Jan 12, 2013 at 7:07 PM, BjornBacklund <notifications@codeplex.com> wrote:

From: BjornBacklund

I get this but for people like me that only does TS programming (and C#), this wouldn’t matter, I would love to have a switch in the compiler that would enable ‘implicit this”.
Another related issue is the lack of nested block scope as in C#, it's somewhat frustrating that you cannot use blocks to introduce new variable like below, any chance support for this could be added as a switch to the compiler?
{
From: ahejlsberg
Sent: January 12, 2013 9:30 AM
To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: ahejlsberg

Also, a real problem is that an implicit 'this' would in some cases change the meaning of the code. For example:

var x = 10;
class Foo {
    x = 20;
    f() {
        console.log(x);
    }
}
var foo = new Foo();
foo.f();

In ES6 this is supposed to output '10', but it would output '20' with an implicit 'this'. We would basically break perfectly valid ES6 code!

Anders

Read the full discussion online.

To add a post to this discussion, reply to this email (typescript@discussions.codeplex.com)

To start a new discussion for this project, email typescript@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Read the full discussion online.

To add a post to this discussion, reply to this email (typescript@discussions.codeplex.com)

To start a new discussion for this project, email typescript@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Jan 13, 2013 at 6:17 PM
Yes looked at Script# but I don’t want to bet on something not backed by a larger player (such as MS in this case).
From: markrendle
Sent: ‎January‎ ‎13‎, ‎2013 ‎10‎:‎00‎ ‎AM
To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: markrendle

Maybe you should look at Script# https://github.com/nikhilk/scriptsharp ?


On Sun, Jan 13, 2013 at 4:32 PM, BjornBacklund <notifications@codeplex.com> wrote:

From: BjornBacklund

One switch to turn TS more into C# would be sufficient 😊
Honestly, I’m working on a larger project with TS for the UI and C# for the backend and it would be great to be able to use the same style of programming in both worlds. TS is so much better than JS but it could be made even better if the “ES6 alignment goal” would be dropped (or overridden by aforementioned switch)
---bjorn
From: markrendle
Sent: ‎January‎ ‎13‎, ‎2013 ‎7‎:‎21‎ ‎AM

To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: markrendle

How many compiler switches do you want!?


On Sat, Jan 12, 2013 at 7:07 PM, BjornBacklund <notifications@codeplex.com> wrote:

From: BjornBacklund

I get this but for people like me that only does TS programming (and C#), this wouldn’t matter, I would love to have a switch in the compiler that would enable ‘implicit this”.
Another related issue is the lack of nested block scope as in C#, it's somewhat frustrating that you cannot use blocks to introduce new variable like below, any chance support for this could be added as a switch to the compiler?
{
From: ahejlsberg
Sent: January 12, 2013 9:30 AM
To: bjorn@backlund.org
Subject: Re: Make "this" the default context inside classes [typescript:429350]

From: ahejlsberg

Also, a real problem is that an implicit 'this' would in some cases change the meaning of the code. For example:

var x = 10;
class Foo {
    x = 20;
    f() {
        console.log(x);
    }
}
var foo = new Foo();
foo.f();

In ES6 this is supposed to output '10', but it would output '20' with an implicit 'this'. We would basically break perfectly valid ES6 code!

Anders

Read the full discussion online.

To add a post to this discussion, reply to this email (typescript@discussions.codeplex.com)

To start a new discussion for this project, email typescript@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Read the full discussion online.

To add a post to this discussion, reply to this email (typescript@discussions.codeplex.com)

To start a new discussion for this project, email typescript@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Jan 14, 2013 at 3:50 PM

Just some wild idea, how about allowing lambda like function declaration within a class where this would be the default context (of course this would not be 100% aligned with the ES6 proposal, but who knows they are willing to include it ;). So in the above example:

var x = 10;
class Foo {
    x = 20;
    f() {
        console.log(x); // prints 10
    }

    g() => {
        console.log(x); // prints 20
    }

}
var foo = new Foo();
foo.f();

// Peter

Feb 28, 2013 at 1:19 PM
Coffeescript provides a shorthand for this.foo in the form @foo, but my vote is for implicit this, if I do manage to shadow a member inside a class, which is pretty rare, its a simple matter to change it. Having to constantly think about 'this' in classes and have every single member access qualified is a real pain point.
Mar 5, 2013 at 2:31 PM
What if in this case TS compiler would generate an error message about ambiguous expression, so the programmer would specify "this" explicitly (only) in this case?
I think that "this." - polluted code will cause serious programmer productivity slowdown and will scare-off many newcomer programmers.

Thank you.

ahejlsberg wrote:
Also, a real problem is that an implicit 'this' would in some cases change the meaning of the code. For example: var x = 10; class Foo { x = 20; f() { console.log(x); } } var foo = new Foo(); foo.f(); In ES6 this is supposed to output '10', but it would output '20' with an implicit 'this'. We would basically break perfectly valid ES6 code! Anders
Mar 6, 2013 at 9:35 AM
Edited Mar 6, 2013 at 10:30 AM
As a C# Programmer, even I am beginning to tire of these "make it more like C#" requests.
There is plenty of things still to desire from TS, but making it more like C# is not one of them.

It is true that you trip up every now and then when your use to that world, but the more this stay true to JavaScript and ECMA6, the better in my mind and Anders and his team is doing a great job at this in my mind.

And as Anders says, this would break working code... Although odd code maybe.
var greet = "Global says Hello to";
module mod {
    var greet = "Module says Hello to";
    export class cls {
        //var greet = "Class says Hello to";
        name: string;
        greet = "Class says Hello to"; //This is not the thing being used.
        constructor(name: string) {
            this.name = name;
        }
        speak() {
            return greet + " " + this.name;
        }
    }
}

var x = new mod.cls("Anders");
$("#msg").html(x.speak());
One thing about the above though, we allow to define scoped variables up until classes, outside of typescript this would work:
var greet = "Global says Hello to";
var mod;
(function (mod) {
    var greet = "Module says Hello to";
    var cls = (function () {
        var greet = "Class says Hello to";
        function cls(name) {
            this.name = name;
        };
        cls.prototype.speak = function (element) {
            return greet + " " +this.name;
        };
        return cls;
    })(); 
    mod.cls = cls;
})(mod || (mod = {}));

var x = new mod.cls("Anders");
$("#msg").html(x.speak());
http://jsfiddle.net/bCNzN/1/

So maybe the ability to defined scoped variables inside "classes" is missing and maybe we should allow for that like so:
class cls {
        var scoped_var = "scoped variable";
        public pub_var = "public variable";
        private pri_var = "Private in TS, but still public variable";
    }
}

var x = new mod.cls("Anders");
$("#msg").html(x.speak());
Not sure if that would have any implications.

In any case, that is a very different subject to the one this thread is about.
Mar 6, 2013 at 10:06 AM

I agree. The ES6 compatibility pledge is one of the things that gives TypeScript credibility in the non-MS world. I'm far happier knowing that the team are hard at work on generics, and hoping that a 1.0 release will follow shortly after they release that feature.

On 6 Mar 2013 10:35, "jmelgaard" <notifications@codeplex.com> wrote:

From: jmelgaard

As a C# Programmer, even I am beginning to tire of these "make it more like C#" requests.
There is plenty of things still to desire from TS, but making it more like C# is not one of them.

It is true that you trip up every now and then when your use to that world, but the more this stay true to JavaScript and ECMA6, the better in my mind and Anders and his team is doing a great job at this in my mind.

And as Anders says, this would break working code... e.g.
var greet = "Global says Hello to";
module mod {
    var greet = "Module says Hello to";
    export class cls {
        //var greet = "Class says Hello to";
        name: string;
        constructor(name: string) {
            this.name = name;
        }
        speak() {
            return greet + " " + this.name;
        }
    }
}

var x = new mod.cls("Anders");
$("#msg").html(x.speak());
One thing about the above though, we allow to define scoped variables up until classes, outside of typescript this would work:
var greet = "Global says Hello to";
var mod;
(function (mod) {
    var greet = "Module says Hello to";
    var cls = (function () {
        var greet = "Class says Hello to";
        function cls(name) {
            this.name = name;
        };
        cls.prototype.speak = function (element) {
            return greet + " " +this.name;
        };
        return cls;
    })(); 
    mod.cls = cls;
})(mod || (mod = {}));

var x = new mod.cls("Anders");
$("#msg").html(x.speak());
http://jsfiddle.net/bCNzN/1/

So maybe the ability to defined scoped variables inside "classes" is missing, but that is in my mind a very different subject to the one this thread is about.

Read the full discussion online.

To add a post to this discussion, reply to this email (typescript@discussions.codeplex.com)

To start a new discussion for this project, email typescript@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Mar 6, 2013 at 2:34 PM
I agree it is minorly burdensome to write this all over the place, but on the other hand, TS is not C# and as Anders illustrated, it's very clear why it's necessary. Modules in TS are closer to static classes in C# than they are to namespaces. The fact that modules, and indeed, the global scope, can contain variables and functions makes some kind of qualification for class members necessary.

If anything, I'd support a shortcut @ to access member variables/functions, though this seems pretty low priority on a wish list of features.
Mar 18, 2013 at 9:59 AM
I vote for explicitly forcing developers to type "this" . It forces us to be responsible in how we code our scopes!.


I've been slowly building my own UI framework on top of TypeScript, and as painful as it is to keep writing "this. " its forcing me to think about the scope within my functions/methods/classes/modules etc.
Mar 22, 2013 at 9:14 PM

Hello, Anders and everybody!

Stop, stop, stop! This is TypeScript or not TYPE Script? And what type this is? Who knows?

We BADLY need to bind this keyword to object context somehow. ECMAScript was ugly bastard (as well as ECMAScript 6) and we do not want another peace of s... but just strongly typed. Every JavaScript developer sooner or later makes this hack:
function MyClass() {
    var _this = this;
    ...
}
Every one and every time.

If you do not want to break existing behavior yo can use another keyword: 'me', 'self', '@', '@this' or bind with alternative syntax: method() =>{ ... }. You know it. But please DO SOMETHING or TypeScript will fail against CoffeeScript. We need syntax sugar.

Thanks.
Mar 23, 2013 at 1:49 AM
I will vote for explicit this keyword.

As a functional programming language ECMAScript, the class SHOULD NOT be the most important thing. This in ECMASCRIPT make a lot thing dynamic and convinent. For example, if I want to make some function general for all of class, everything I shou do is just create a function, and use it like

Func.call( someObj )

And the this in the function will be the someObj.

For the method in a class, it's shoule be a same FUNCTION. Anyhow the TypeScript is a syntax sugar of ECMAScript, not another language like c# or coffee script etc.
Apr 11, 2013 at 2:36 PM
Edited Apr 11, 2013 at 2:40 PM
I would LOVE to see something like @this or self to exist, or some way of not having to shoe horn almost all my code into the constructor which is AWFUL (imo). As I currently make heavy use of event systems to relay messages throughout the systems and lawnchair, knockout, jquery etc they all swap and change the this context. In the case of lawnchair there was no nice solution to the problem:

http://stackoverflow.com/questions/15679838/using-lawnchair-with-typescript

As some of my view models are pretty big, even after they have been broken up into smaller components it is horrible to look at the constructor having reams of code in it, and then there is the documentation comments put on above to generate the documentation for plugin developers to use. It just ends up looking like a huge mess.

Currently for me Typescript has worse this handling than raw JS only because it stills allows the overwriting of the keywords scope but also forces you to use this as a prefix for calling any class methods. So you are unable to use the old JS trick of:
function SomeClass()
{
    var self = this;
    
    this.AlertSomething = function(something) { alert(something); };
    this.SomeCallbackWithScopedThis = function() { self.AlertSomething(this); }
}
As the same example in typescript would not work, as shown here:
class SomeClass
{
    private self: any;
    constructor() { this.self = this; }
    
    public AlertSomething = function(something) { alert(something); };
    public SomeCallbackWithScopedThis = function() { this.self.AlertSomething(this); } // you need the this prefix making it pointless
}
So it is like Typescript is forcing you to write your code with the this always meaning the context of the class when you want to invoke its methods, but also allowing others to play with the this scope so you can NEVER be sure as to where your methods are being invoked from and what scope has been tampered with, as even our simple methods which do business logic and never touch the UI may be triggered from an ajax callback which was triggered from a UI event which ends up invoking with an altered scope.

If you could at least have lambda style class level methods to have a locally inferred this it would solve a huge amount of these problems, but for me it seems like the current implementation is too unstable for serious development of large UI projects... and yes I know I could put it all in the constructor, but that to me is a work around, not a solution.

== Edit ==

Just to be clear I am not really for having the default scope of this being the current class instance, I think it should be left as it is in JS. I am however for another means to access the current instance or at least cache it for usage... just some way of being able to guarentee the context of the instance OUTSIDE of the constructor.
Apr 11, 2013 at 8:53 PM
I like that TypeScript is basically just JavaScript (or ECMAScript 6) with type extensions. Changing the way "this" works would break that distinction. Then TypeScript would be some other language like AS3. If you want that kind of functionality, might as well use one of those (Jangaroo and FalconJx can compile AS3 to JS if you want!).

That said, maybe we can at least get the coffeescriptesque @ operator to cut down on some of the typing? this.prop would become @prop. Clean and simple.

Also, you should never have to shoehorn everything into a constructor. I've seen that a couple of times on these forums (and I'm not here often). You can use a local reference in the current scope chain and method.call (the way vanilla JS users do it) or you can use the "arrow function" syntax (aka the "fat arrow") which basically sets that up for you. It's cleaner than stuffing everything into a constructor.
Apr 12, 2013 at 7:19 AM
@CaptainN Could you please show me some examples of what you mean in the latter paragraph? I know that the lambda style methods should set the this scope correctly, however I am unable to define my methods using that mechanism as it tells me that the this keyword cannot be used in that context i.e:
class SomeClass
{
    private SomeObject: any;
    public SomeCallbackMethod = (result) => { this.SomeObject.InvokeSomething(result); }
}
Not sure what you mean by the method.call way, but if you could post examples of what you mean in both cases it would be very helpful to me and im sure others, as there is VERY LITTLE useful information on the ways to access this correctly outside of the constructor and guarantee the scope would be fine regardless of where it is invoked from.

I have an SO question along these lines (Although not 100% relevant), which I would be happy to upvote if you put the examples in.

http://stackoverflow.com/questions/15925500/issue-with-child-scoping-of-this-in-typescript
Jun 17, 2013 at 7:29 PM
Dubrovsky wrote:

Hello, Anders and everybody!

Stop, stop, stop! This is TypeScript or not TYPE Script? And what type this is? Who knows?

We BADLY need to bind this keyword to object context somehow. ECMAScript was ugly bastard (as well as ECMAScript 6) and we do not want another peace of s... but just strongly typed. Every JavaScript developer sooner or later makes this hack:
function MyClass() {
    var _this = this;
    ...
}
Every one and every time.

If you do not want to break existing behavior yo can use another keyword: 'me', 'self', '@', '@this' or bind with alternative syntax: method() =>{ ... }. You know it. But please DO SOMETHING or TypeScript will fail against CoffeeScript. We need syntax sugar.
Completely agree.
Could someone from the TS team shed the light on progress in this direction? It`s really pain in the a.. when implementing methods that should access local variables. You end up with constructor pollution which became very ugly for the big classes.
Developer
Jun 18, 2013 at 3:05 PM
We are planning to lift the restriction on accessing 'this' in property initializers so you can initialize properties with lambdas. That should go a long way towards addressing this problem.

More details here: http://typescript.codeplex.com/discussions/447071
Feb 10 at 12:12 PM
Agree with Dubrovsky and armsoft - TypeScript does't need to replicate ECMAScript puzzles with "this".
It should be object context bound 1) because it's sweet 2) because it fits TypeScript philosophy.
Compatibility issues between TS's 'this' and ECMAScript's 'this' could be transparently solved on tsc state, without even need to introduce another keyword.