3 ms·

> 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 underst

by iamjs 10y ago

> 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 10y ago
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 10y ago
  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.
  - shp0ngle 10y ago
    Once I started using arrow notations, I stopped worrying about `this`. Whenever I need to export class function, I do var foo = () => bar.baz() , no more worrying, no need to understand what the hell bind does exactly. Also with the ... notation, I stopped worrying about .call and .apply. So I can write var someArray = [a,b,c] var foo = () => bar.baz(...someArray) and so on.

by iamjs 10y ago

munificent 10y ago

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 10y ago
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.
- shp0ngle 10y ago
  Once I started using arrow notations, I stopped worrying about `this`. Whenever I need to export class function, I do var foo = () => bar.baz() , no more worrying, no need to understand what the hell bind does exactly. Also with the ... notation, I stopped worrying about .call and .apply. So I can write var someArray = [a,b,c] var foo = () => bar.baz(...someArray) and so on.