6 ms·

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 "impl

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.

megous 8y ago
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.
- NathanKP 8y ago
  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.)
  - megous 8y ago
    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.
wakamoleguy 8y ago
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.
- harimau777 8y ago
  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?
  - weberc2 8y ago
    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.
  - jhanschoo 8y ago
    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.
    - zeroname 8y ago
      > 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.
- spankalee 8y ago
  super fixes that use case though.

megous 8y ago

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.

NathanKP 8y ago
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.)
- megous 8y ago
  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.

wakamoleguy 8y ago

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.

harimau777 8y ago
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?
- weberc2 8y ago
  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.
- jhanschoo 8y ago
  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.
  - zeroname 8y ago
    > 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.
spankalee 8y ago
super fixes that use case though.