Hacker News Reader

Comment by zeroname | Hacker News Reader

You can also "easily" forget to call bind. In other languages, methods are simply bound by default. What's the argument for not doing it that way (besides "implementation details")? Why would you rebind a method in the first place? Seems like a "great" way to cause confusion.

View on HN

In other languages, classes are a special entity. In JS it's just another object, and you can copy methods from one object to another. Benefit is that you can create mixins, for example.

Yep, the concept of the "prototype" is very integral to JavaScript, and I think its often not understood fully. I actually like the mixin concept much more than multiple inheritance, as I find the mental model to be a bit clearer. For example the "diamond problem" is very clear with a mixin and easily resolved (latest mixin wins) vs more confusing in many languages (looking at you Go with "ambiguous selector" error.)

Yes. I use it all the time. What's the best is that you can extend existsing prototypes and add your own functions even to native/host objects. And with a use of Symbols it's quite foolproof.

Rebinding `this` is the key for sharing methods using prototypal inheritance. It allows methods on the prototype object to dynamically dispatch to methods depending on the child you are calling it on.

I had always been taught that inheritance is an anti-pattern and my experience has been that it makes code more complicated. However, I don't have a lot of first hand experience with it. What would the argument be for why you would want to use "this" to implement prototypal inheritance?

Traditional class-based inheritance is an antipattern compared to composition because the child class's API is tightly coupled to its parent: multiple inheritance of implementations is a mess to reason about, and single inheritance unduly privileges a single parent object that makes refactoring hard when the API of the child or parent has to change.

Composition does not face these issues because instead of a parent class, the outside class's API is not beholden to the inside class's API.

Similarly, in prototypal inheritance, you get to specifically control API by binding or calling 'this' to any choice of object, or select methods to put in other objects, or even replace a method of an object with another method of the same name at runtime, or declare new fields and methods on objects at runtime. This makes prototypal inheritance very open for extension in a way that class-based inheritance cannot be. The downside to this is that JS does not have language features that sufficiently guarantee that an object is closed for modification: in class-based languages classes are a language feature that give a sort of guarantee about the API of an object, but JS objects have no mechanism as powerful as that, and you will need to roll your own. Hence the eventual development of languages and extensions to JS like TS, Reason, Flow that offer these guarantees that transpile to JS.

> Similarly, in prototypal inheritance, you get to specifically control API by binding or calling 'this' to any choice of object, or select methods to put in other objects, or even replace a method of an object with another method of the same name at runtime, or declare new fields and methods on objects at runtime.

None of this sounds like a good idea to me.

Indeed it isn't, and is very lousy to reason about with... until you avail yourself to the sophisticated type systems more commonly found in ML and Haskell through, say, Flow or TypeScript that gives you good guarantees through static analysis as you write.

Honestly there’s no use for prototypical inheritance. You get simpler code by avoiding it altogether as with standard OOP inheritance. You were taught correctly.

super fixes that use case though.

Reply on news.ycombinator.com