4 ms·

I agree now that what Eric Elliot is doing is not composition. But it's not inheritance as it is commonly known either. If I inherit from a prototype, then inhe

I agree now that what Eric Elliot is doing is not composition. But it's not inheritance as it is commonly known either. If I inherit from a prototype, then inherited objects can use the prototype methods via prototype delegation. If I change a method in the prototype, inherited objects will see that change. Which is similar to class based inheritance, but can happen at run time. That will not happen with Object.assign because it is cloning or copying. If I make a change to a prototype I cloned from, the cloned object will not be changed. This is also known as concatenative prototyping. Yes, it's considered a type of inheritance, but I think different enough from prototype delegation and class inheritance that it should be pointed out when claiming it is inheritance. Because copying feels closer to composition than than it does to OO inheritance or prototype delegation IMO. Composition still wins though. Good discussion. "By absolutely no one ever. :)" Actually, quite often. A few examples below: https://en.wikipedia.org/wiki/Prototype-based_programming#Concatenation https://en.wikipedia.org/wiki/Prototype-based_programming#Co... http://aaditmshah.github.io/why-prototypal-inheritance-matters/ http://aaditmshah.github.io/why-prototypal-inheritance-matte... http://www.datchley.name/understanding-prototypes-delegation-composition/ http://www.datchley.name/understanding-prototypes-delegation...

Lazare 10y ago
> But it's not inheritance as it is commonly known either. Wikipedia disagrees; do you have a citation in mind? > Which is similar to class based inheritance, but can happen at run time. That's not a distinguishing feature of class based inheritance; many implementation do this. Python's class based inheritance is extremely flexible and absolutely allows run time modification; to a greater or lesser extent this is true of many dynamic language (Ruby, Perl, etc.). What do you think the defining feature of class based inheritance is that allows a clean distinction between JS and Python? Because I don't personally see much of one. > Because copying feels closer to composition than than it does to OO inheritance or prototype delegation IMO. Well, opinions are subjective. My experience has been the reverse, however.
- tchaffee 10y ago
  > Wikipedia disagrees; do you have a citation in mind? Nowhere in the wikipedia main article about inheritance does it cover concatenation inheritance (https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) https://en.wikipedia.org/wiki/Inheritance_(object-oriented_p...). You only find it in the article about Prototype based programming (https://en.wikipedia.org/wiki/Prototype-based_programming https://en.wikipedia.org/wiki/Prototype-based_programming). It's also my personal experience (started with Java when it was first released...) that inheritance means class-based inheritance to a lot of devs. I'm sure that changes depending on which devs you hang out with. If I understand right, concatenation is more commonly called a mixin? At least the way it's done in javascript. In which case the wikipedia article on that says 'Mixins are sometimes described as being "included" rather than "inherited". Mixins encourage code reuse and can be used to avoid the inheritance ambiguity that multiple inheritance can cause' Based on that last quote, I'm confident I'm not the only one with the opinion that concatenation inheritance isn't a strict "is-a" relationship and might veer towards "has-a". Maybe "has-a-trait" type relationship? That's also how Eric Elliot was using Object.assign. A guitar has distortion, volume, and a cabinet. Let's not go in circles: I still agree his code isn't composition. But mixins sure do blur the lines between composition and inheritance for me. > That's not a distinguishing feature of class based inheritance It was an aside. Not very important to the point I was making. The point was that prototype delegation and class inheritance are similar in the way that methods are inherited, and that's different from how concatenation treats methods. But thanks for the info, I didn't know that about Python.

Lazare 10y ago

> But it's not inheritance as it is commonly known either. Wikipedia disagrees; do you have a citation in mind? > Which is similar to class based inheritance, but can happen at run time. That's not a distinguishing feature of class based inheritance; many implementation do this. Python's class based inheritance is extremely flexible and absolutely allows run time modification; to a greater or lesser extent this is true of many dynamic language (Ruby, Perl, etc.). What do you think the defining feature of class based inheritance is that allows a clean distinction between JS and Python? Because I don't personally see much of one. > Because copying feels closer to composition than than it does to OO inheritance or prototype delegation IMO. Well, opinions are subjective. My experience has been the reverse, however.

tchaffee 10y ago
> Wikipedia disagrees; do you have a citation in mind? Nowhere in the wikipedia main article about inheritance does it cover concatenation inheritance (https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) https://en.wikipedia.org/wiki/Inheritance_(object-oriented_p...). You only find it in the article about Prototype based programming (https://en.wikipedia.org/wiki/Prototype-based_programming https://en.wikipedia.org/wiki/Prototype-based_programming). It's also my personal experience (started with Java when it was first released...) that inheritance means class-based inheritance to a lot of devs. I'm sure that changes depending on which devs you hang out with. If I understand right, concatenation is more commonly called a mixin? At least the way it's done in javascript. In which case the wikipedia article on that says 'Mixins are sometimes described as being "included" rather than "inherited". Mixins encourage code reuse and can be used to avoid the inheritance ambiguity that multiple inheritance can cause' Based on that last quote, I'm confident I'm not the only one with the opinion that concatenation inheritance isn't a strict "is-a" relationship and might veer towards "has-a". Maybe "has-a-trait" type relationship? That's also how Eric Elliot was using Object.assign. A guitar has distortion, volume, and a cabinet. Let's not go in circles: I still agree his code isn't composition. But mixins sure do blur the lines between composition and inheritance for me. > That's not a distinguishing feature of class based inheritance It was an aside. Not very important to the point I was making. The point was that prototype delegation and class inheritance are similar in the way that methods are inherited, and that's different from how concatenation treats methods. But thanks for the info, I didn't know that about Python.