[Feature Request] Support for 'self' keyword in classes which is more specific than 'this' keyword

[devssh]

Is your feature request related to a problem? Please describe.
Using 'this' is confusing in classes as it could refer to the class or the current function in the class.
I have spent a lot of time writing code where there is an error and it turns out to be an oversight of the scope for 'this' when refactoring code to a function.

Describe the solution you'd like
The same solution provided by Scala which is to add a keyword called 'self'
So 'self.function1' refers to the class.function1 while 'this.function1' refers to the local scope of the function.

Describe alternatives you've considered
a simple hack for this is to create a variable 'self' in every class and assign it to 'this' in the beginning, another solution would be to use 'class1.function1' instead of 'this.function1' but working in a team means that other people end up writing 'this.function1' leaving me to figure out the scope and this restricts readability

Teachability, Documentation, Adoption, Migration Strategy
Users will understand this if they have worked in languages like scala or if they do a quick search for the keyword

[nicolo-ribaudo]

https://github.com/rbuckton/proposal-class-access-expressions

Does this proposal do what you want?

[nicolo-ribaudo]

https://github.com/rbuckton/proposal-class-access-expressions

Does this proposal do what you want?

[devssh]

No it does not. That is a different use case, the static class is the same as Class.function, whereas the 'self' keyword need not be static

[devssh]

No it does not. That is a different use case, the static class is the same as Class.function, whereas the 'self' keyword need not be static

[nicolo-ribaudo]

Ok, I initially misunderstood your request.

self as a keyword will never be added, because it would be a breaking change:

var self = 2;
class A {
  foo() {
    return function () {
      console.log(self); // 2
    }
  }
}

If you don't want to loose the this context, just use arrow functions "by default".

Anyway, the correct place to discuss a new ECMAScript feature is the https://esdiscuss.org mailing list 😉

[nicolo-ribaudo]

Ok, I initially misunderstood your request.

self as a keyword will never be added, because it would be a breaking change:

var self = 2;
class A {
  foo() {
    return function () {
      console.log(self); // 2
    }
  }
}

If you don't want to loose the this context, just use arrow functions "by default".

Anyway, the correct place to discuss a new ECMAScript feature is the https://esdiscuss.org mailing list 😉

[devssh]

Haha I see, just a suggestion since it seems handy to have and nobody seems to have reported this yet.

ES does have breaking changes from time to time as long as the benefits outweigh the downside.
Yes, I usually use arrow functions but unfortunately I work in React, and when it is not possible to have stateless functions I have to work on functions in React Components.
Plus there are a lot of blog posts about using the 'self' keyword in ES which shows how much people want it

https://stackoverflow.com/questions/34483888/difference-between-bind-and-var-self-this
https://groups.google.com/forum/#!topic/nodejs/1cTO_cJVxUg
https://medium.com/@vijay.j.shekhawat/javascript-why-var-self-this-bbbaf98ab9d9
http://blog.iangilman.com/2015/02/self-this.html

Thanks for the reference to esdiscuss

[devssh]

Haha I see, just a suggestion since it seems handy to have and nobody seems to have reported this yet.

ES does have breaking changes from time to time as long as the benefits outweigh the downside.
Yes, I usually use arrow functions but unfortunately I work in React, and when it is not possible to have stateless functions I have to work on functions in React Components.
Plus there are a lot of blog posts about using the 'self' keyword in ES which shows how much people want it

https://stackoverflow.com/questions/34483888/difference-between-bind-and-var-self-this
https://groups.google.com/forum/#!topic/nodejs/1cTO_cJVxUg
https://medium.com/@vijay.j.shekhawat/javascript-why-var-self-this-bbbaf98ab9d9
http://blog.iangilman.com/2015/02/self-this.html

Thanks for the reference to esdiscuss

[ljharb]

@devssh in react, the pattern you want is a normal instance method foo, with this.foo = this.foo.bind(this) in the constructor.

Since every function invocation can redefine this, there's no way to achieve what you want for the instance short of autobinding every method, which would break a lot of legitimate use cases - and the linked proposal above covers the static use case, for which you would currently hardcode the class name.

See https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md for how to suggest new features.

[ljharb]

@devssh in react, the pattern you want is a normal instance method foo, with this.foo = this.foo.bind(this) in the constructor.

Since every function invocation can redefine this, there's no way to achieve what you want for the instance short of autobinding every method, which would break a lot of legitimate use cases - and the linked proposal above covers the static use case, for which you would currently hardcode the class name.

See https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md for how to suggest new features.

[devssh]

I already know about this.foo = this.foo.bind(this)
I meant this issue facebook/react#2899 which is closed for the same reason, breaking changes.
I think I get your point though, there are workarounds for it, just no syntactic sugar(as it would be a breaking change)

[devssh]

I already know about this.foo = this.foo.bind(this)
I meant this issue facebook/react#2899 which is closed for the same reason, breaking changes.
I think I get your point though, there are workarounds for it, just no syntactic sugar(as it would be a breaking change)