|
|
|
|
|
|
by stupidcar
2998 days ago
|
|
|
A lot of these examples seem rather contrived, and the whole appendix has a very FUDy feel to it. It seems like the author didn't like classes in JS, and set-out to come up with some examples to justify their dislike, rather than coming to that conclusion through actually encountering these problems in the real world. Something not helped by the weaselly tone, constantly implying that it's just raising concerns, when it's clearly been written by somebody with an extremely strong anti-classes mindset. As a simple way to define a reusable bundle of behaviour of logic, or to construct simply base-class -> specialisation inheritance hierarchy, JS classes work fine. |
|
|
> If you change/replace a method (on purpose or by accident) on the parent "class", the child "class" and/or instances will still be "affected"
I knew when reading this line exactly what the author was about to do to mislead the unsuspecting user. Directly edit the prototype and feign surprise. The prototype is representative of the class itself, basically a default of all properties for that class. The correct (and obvious) way to override a class method for only one member of the class is to assign a new function on the property directly, not into the prototype's version of the property. Class definitions being mutated in an application is extremely uncommon. This is like putting your hand on a hot stovetop and then complaining that you burnt yourself.