There is a bit more nuance in using `this` in a named function that wasn't covered. Named functions defined in classes are scoped outside of the class, meaning they are not bound to the class. To use `this` in your named function, you usually have to bind it in the constructor using `this.functionName.bind(this)`
Arrow functions defined within a class are scoped and bound to the class automatically. Hence, arrow functions do not require calling the .bind in constructor, and you can happily use `this` inside arrow functions.
Late binding is also what the above poster is complaining about and they mention the habit some have in class constructors for "early binding" to try to avoid it.
The `class` keyword is as much "just" syntax sugar for stuff you can do without the `class` keyword. The behaviors are the same.
Late binding happens whether or not the function is a part of the Object's prototype chain or directly attached. JS is built so that's all mostly the same thing. That's why late binding exists. Maybe you copy a function from one prototype to another to create a new sort of prototype with a bit of "code-sharing", which is the same if you want to copy a function directly from one object to another. You want that function to work in all these cases, you don't want to redefine the function explicitly for a different kind of prototype or a different kind of object, you want to pick up what it is bound to by how it is called (thus late binding). Late binding is an ancient feature of JS that feels like a bug if you think `class` works like it does in OO languages like C++ or Java or C#. Late binding feels like a bug if you think of an Object's prototype as being a strongly formed contract and not a runtime object that itself can change at any time, or can be used as a lego brick to construct other types of objects and code-sharing beyond traditional class-based OOP "inheritance" models.
The difference between a "regular object" and thing constructed from a `class` in JS is effectively nonexistent. It's the same stuff, just a few syntax niceties. (In the old days, it was a lot harder to build a clean prototype, `class` makes it a lot cleaner. But that's all it does, it makes it cleaner to write, but under the hood it is entirely the same as it was.)
> in the constructor, using arrow functions?
The example above was the related but similar thing of doing `this.a = this.a.bind(this)` in a class constructor. It's very similar to using `this.a = () => …` arrow functions to early bind `this`. (Assigning a function to itself in a constructor with a `bind()` is also an idiom pattern that predates arrow functions and class syntax. Constructors predate class syntax, but they used to look a lot different. You can still write that form of constructor if you want, but class syntax is a lot cleaner.)
Late binding is an old feature that feels like a bug today, so a lot of people work very hard to early bind functions or only ever use arrow functions because they don't trust late binding.
Yes, I think we are on the same page. I did not want to include "legacy" prototype-based inheritance examples because I'm on a phone and didn't want to make complexity
explode here.
Also I made a weird statement here:
> That can also be done after the class was declared?
That doesn't make much sense for binding "this" to the class that was declared, I wsd mixing up arrow function class properties inside the class declaration with adding prototype properties (which is exactly what one doesn't want for classes with many instances).
In the scope of the class declaration, all methods of adding methods to the prototype are awkward, I guess.
Regarding the "early-binding" using .bind or arrow functions in constructor, I see your points, and it's the subtle and hard-to-explain differences that are really annoying.
JS really requires some discipline and sticking to a pit of success, while it's still essential to know the basics.
> Late binding is an old feature that feels like a bug today, so a lot of people work very hard to early bind functions or only ever use arrow functions because they don't trust late binding
Yes, that's what I was going at, thanks for making clear the difference between arrow functions (lexical scoping) and using `bind` (arbitrarily fixed "this").
I was lately (no pun!! really coincidence, it just wasn't only recently) using late binding with object literals in tests with Jest and TS and had to ignore TS there, it's pretty much the major reason I'm commenting here. It was convenient and succinct for a mock object implementing an interface otherwise used by class instances to use late binding.
Arrow functions defined within a class are scoped and bound to the class automatically. Hence, arrow functions do not require calling the .bind in constructor, and you can happily use `this` inside arrow functions.