[iamjs]

> The thing I like about classes is I vaguely understand what is going on [...] I am not saying the javascript prototype logic is bad, just that I never understood it, even when I work in Javascript for years.

But by using classes, you're still using prototypes, it just isn't as immediately apparent.

[munificent]

Sure, and by using classes in C++, you're still using tables of functions pointer like you can in C. The "not as immediately apparent" part is where the usability improvement comes from. It means you don't need to think about the machinery as much. You can work at a higher level of abstraction.

(Of course, the details of how the feature is designed determine how leaky the abstraction is and how often you actually get the luxury of not thinking about the machinery.)

[dsp1234]

I think understanding "this" in javascript is actually much easier if you have had exposure to C++ function tables.

With that knowledge in hand, it immediately becomes obvious that:

  bar.baz = function(){console.log(this.X)}
  var foo = bar.baz;
  foo();

Is not going to result in a console log of bar.X. "foo" is a pointer-to-member function, and executing it without a context is going to cause problems. The biggest in javascript as compared to c++ is that javascript will always provide the hidden "this" (even if it's the global context), whereas c++ will always bail out if you don't provide it with a proper context.

But really, understanding that behind the scenes, member function calls change:

  A.B(C)

  into

  B(A, C)

clears up a lot of "this" mistakes, and also enlightens the proper usage of function.bind.