[moritzwarhier]

The article misses even more nuance, independent from classes.

If you define

  const o = { a: "Hello", b() { return this.a;} }

then

  o.a()

will return "Hello"

while

  const b = o.b; // not a.b ...
  b();

will throw an error.

This predates generator functions and classes (which are only syntax sugar AFAIK).

And it seems like a glaring omission giving the submission title.

I'm ashamed though if it's in there and I missed it.

The behavior is called "late binding".

[WorldMaker]

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.

[moritzwarhier]

Thanks for explaining, maybe I was missing the point there.

I was replying with this because it happens without using the "class" keyword (or "constructor") at all.

Not sure what you mean with the class constructor thing, but that's on me. I still don't understand these properly:

> Named functions defined in classes are scoped outside of the class, meaning they are not bound to the class

> the habit some have in class constructors for "early binding" to try to avoid it.

You mean using sth like

  this.a = //...

in the constructor, using arrow functions?

I guess I'm missing something here.

That can also be done after the class was declared? The class keyword is only syntax sugar.

Anyway, I might be missing something important here.

That's why I brought up an example using an object literal, which has the prototype

  Object.prototype

Try it:

  const a = {};
  console.log(Object.getPrototypeOf(a) === Object.prototype); // logs "true"

These shenanigans are why I sometimes hate JS, but also agree that we should aim to understand the basics first.

I love MDN for that.

https://developer.mozilla.org/en-US/docs/Learn_web_developme...

[WorldMaker]

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.

[moritzwarhier]

Thank you for responding!

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.

[postalrat]

Of course it's an error. 'a' isn't defined.

[moritzwarhier]

Lol, thanks, edited