3 ms·

The thing is, you can't really avoid them. It's an important part of the language, and not understanding my bring you pain. In mid-late-2000s when the first id

The thing is, you can't really avoid them. It's an important part of the language, and not understanding my bring you pain. In mid-late-2000s when the first idea of adding classes to the syntax came up, even Microsoft eventually said: nah, it's a bad idea. It's grafting incompatible concepts onto a language that doesn't need them. And then Google in their "wisdom" went and forced classes onto the language. Take a guess why you need this for methods to work the way you expect them: class Logger { constructor () { this.method = this.method.bind(this); } method (some, params) { this.do_stuff() } /// ... }

vore 4y ago
I don't think you need prototypes to understand this, though it is maybe a consequence of them. If you remember that functions are just always free functions and calling them without a context means `this` has no context (unless they are bound or declared with a fat arrow), then I think that gets you 100% of the way there. `this`, of course, is a whole other bag of worms :(
- dmitriid 4y ago
  > I don't think you need prototypes to understand this, though it is maybe a consequence of them. You do indeed need to understand prototypes to explain this behavior. "Free functions" doesn't really make sense, because it obviates the need for classes.
imbnwa 4y ago
Part of my gripe when React moved to class syntax was the loss of auto-binding, not that its an inherent part of prototypes or anything but I didn't get why that should be sacrificed for 'a standard', unless there was stuff I'd forgotten were important gains
- dmitriid 4y ago
  > was the loss of auto-binding, not that its an inherent part of prototypes It is, because classes are a thin wrapper over prototypes, but the whole "classic C++-like" class shenanigans translate very poorly to Javascript. And yet, with maddening bravery browsers have spent 10 years trying to make them work in some capacity (and don't get me started on the whole private members thing, or the autobind proposals, or...)
nicoburns 4y ago
You can also do class Logger { method = (some, params) => { this.do_stuff() } /// ... } But your overall point stands.
mikojan 4y ago
> Take a guess why you need this for methods to work the way you expect them This is not Google's fault. It is the fault of Java developers. They expect everything to work like Java. They expect to find Java APIs everywhere. I have never written classes like that. In fact, if I were to see a method being used in the way you are insinuating I would believe to have found a bug. I strongly dislike class-based object orientation in general. But I'm glad we do not have to deal with dozens of ways to do OOP in JavaScript anymore.
- dmitriid 4y ago
  > This is not Google's fault. It quite literally is. In there desire to push web components they also pushed quite a few (often questionable) solutions. See 17:59 here: https://youtu.be/y-8Lmg5Gobw https://youtu.be/y-8Lmg5Gobw > But I'm glad we do not have to deal with dozens of ways to do OOP in JavaScript anymore. There never were "dozens of ways". There always was only one: prototype based. And now there's this weird contraption on top that pretends its classes from C++-like languages (C++, Java, C# etc.) but is not.

vore 4y ago

I don't think you need prototypes to understand this, though it is maybe a consequence of them. If you remember that functions are just always free functions and calling them without a context means `this` has no context (unless they are bound or declared with a fat arrow), then I think that gets you 100% of the way there. `this`, of course, is a whole other bag of worms :(

dmitriid 4y ago
> I don't think you need prototypes to understand this, though it is maybe a consequence of them. You do indeed need to understand prototypes to explain this behavior. "Free functions" doesn't really make sense, because it obviates the need for classes.

imbnwa 4y ago

Part of my gripe when React moved to class syntax was the loss of auto-binding, not that its an inherent part of prototypes or anything but I didn't get why that should be sacrificed for 'a standard', unless there was stuff I'd forgotten were important gains

dmitriid 4y ago
> was the loss of auto-binding, not that its an inherent part of prototypes It is, because classes are a thin wrapper over prototypes, but the whole "classic C++-like" class shenanigans translate very poorly to Javascript. And yet, with maddening bravery browsers have spent 10 years trying to make them work in some capacity (and don't get me started on the whole private members thing, or the autobind proposals, or...)

nicoburns 4y ago

You can also do class Logger { method = (some, params) => { this.do_stuff() } /// ... } But your overall point stands.

mikojan 4y ago

> Take a guess why you need this for methods to work the way you expect them This is not Google's fault. It is the fault of Java developers. They expect everything to work like Java. They expect to find Java APIs everywhere. I have never written classes like that. In fact, if I were to see a method being used in the way you are insinuating I would believe to have found a bug. I strongly dislike class-based object orientation in general. But I'm glad we do not have to deal with dozens of ways to do OOP in JavaScript anymore.

dmitriid 4y ago
> This is not Google's fault. It quite literally is. In there desire to push web components they also pushed quite a few (often questionable) solutions. See 17:59 here: https://youtu.be/y-8Lmg5Gobw https://youtu.be/y-8Lmg5Gobw > But I'm glad we do not have to deal with dozens of ways to do OOP in JavaScript anymore. There never were "dozens of ways". There always was only one: prototype based. And now there's this weird contraption on top that pretends its classes from C++-like languages (C++, Java, C# etc.) but is not.