-
Notifications
You must be signed in to change notification settings - Fork 25
Could we do something about *this* ? #37
Comments
Wouldn't it be similar to this? with (this) {
...
}
If you want to reduce your usage of Object.assign(this, { firstName, lastName, age }); instead? |
Even though similar to class Person {
// class-field "closure":
firstName;
lastName;
age;
hello() {
// Here, we benefit from refering to class-field closures and can skip 'this'.
return `Hello ${firstName} ${lastName}!`;
}
birthday() {
// Here, we also benefit from refering to class-field closures and can skip 'this'.
++age;
}
}
// A sub class would live in its own closure:
class Clown extends Person {
hatColor;
doTricks() {
// Here, we can refer to hatColor, without specifying `this` but
// when refering to properties defined at super class, we would
// still need to use `this` because we are not in it's closure.
console.log(`My name is ${this.firstName}! Watch me doing some tricks:`);
hatColor = "red";
setTimeout(()=>{
hatColor = "blue";
}, 1000);
}
} |
Ok, I though "class property checking" referred to checking properties on the instance ( Doesn't that introduce a problem with naming arguments though? I think that writing something like this: method(_value) {
value = _value;
} in order to avoid clashing with the field name looks messier than method(value) {
this.value = value;
} And also for me the readability is lost, because |
"Increases the file size" is a non-concern, both because it's negligible, and because gzip takes care of it regardless. As for "readability", I firmly believe that implicitness is what harms readability, not the presence of tokens. Using "this" is strictly superior to having it be implied, imo. |
We're not talking about removing this entirely, are we? If it's just a matter of removing it in the constructor so we don't have to do arg = this.arg all the time, couldn't that be solved via syntax in the constructor parameter like the spread operator. In fact, this wouldn't have to be class specific.... |
@tofagerl that'd be a separate proposal imo. |
I realize that my proposal would not be in line with how methods are accessed, as standardized in ES2015. function doSomething () {
}
class Foo {
someProp;
doSomething () {
}
bar () {
doSomething(); // Refers to outer function as of ES2015, not our method.
someProp = 3; // If this line refers to property, we'd be inconsistent!
}
} I still think it's a pitty though, but too late to change. |
Why would we want to access someprop without this anyway? We'd be confusing everyone by changing established practices. |
I agree with @tofagerl. This will only create confusion and take away code readability. Seriously, is code size really a problem? Coming from a TypeScript user, those Also, as @dfahlander explained, |
@dfahlander I think the problem is that people are using classes more than they should be. I am an avid TypeScript user and I only use classes where frameworks expect them. This is about programming style. Tangentially, regarding verbosity, TypeScript itself requires very few type annotations and works best when you let the inference flow as far as possible. I rarely declare variables without assigning to them (I love |
Could we do about the repeated use of _this_ keyword in class centric Ecmascript code?
Looking at any class centric ES2015 or typescript you will see _this_ being used a lot. IMO this is a problem because it harms the readability and increases the file size. A colleague of mine's reaction over our typescript code was "Somebody has to do something about this" and I agree. The essence of javascript has been small, readable and unbloated code. And we all know the success of that.
Couldn't this proposal also define that closure lookups should include class property checking?
The text was updated successfully, but these errors were encountered: