3 ms·

I can get foo.author.title and foo.post.title no problem using Object.assign: Object.assign({}, { author: author }, { post: post }); Can you give a better e

I can get foo.author.title and foo.post.title no problem using Object.assign: Object.assign({}, { author: author }, { post: post }); Can you give a better example of where a reference to an instance is any different than copying an instance? EDIT: I fixed your example. https://jsbin.com/zamuqoropa/1/edit?js,console https://jsbin.com/zamuqoropa/1/edit?js,console EDIT 2: In fact, my Object.assign does exactly the same thing as your example of composition. And console.log(obj1.author === obj2.author); produces 'true'. https://jsbin.com/vafudizumo/1/edit?js,console https://jsbin.com/vafudizumo/1/edit?js,console Either you're doing composition wrong, or I'm not doing inheritance like you are claiming.

Lazare 10y ago
Object.assign({}, { author: author }, { post: post }); Yep, that's composition and it's identical to my composition example. Of course, you're not actually using Object.assign() to do anything; your code is 100% identical to just saying: {author, post}; Not that there's anything wrong with that...but do note that it's also the exact opposite of what Elliott is advocating for, not what he shows off in his code examples, not what his Stampit library does, etc. > Either you're doing composition wrong, or I'm not doing inheritance like you are claiming. Your first example (and Elliott's examples) are inheritance. Your second example is composition. The difference is enormous. Edit: Elliott says here[0] "Similarly, you can use `Object.assign()` to compose any number of objects together with last-in priority:" let ninjamouse = Object.assign({}, mouse, ninja); 1) That's not composition, that's inheritance. 2) That's the same as your first example, but fundamentally different than your second. He's trying to make a "ninjamouse" which has the properties and methods of both mice and ninjas, because it is a mouse and a ninja. (That's inheritance, and it's fragile for all the reasons inheritance is always fragile). Your second example makes an object that has both a mouse and a ninja. That's composition. "This technique is called concatenative inheritance" By absolutely no one ever. :) [0]: https://medium.com/javascript-scene/common-misconceptions-about-inheritance-in-javascript-d5d9bab29b0a#.jw2f0032r https://medium.com/javascript-scene/common-misconceptions-ab...
- tchaffee 10y ago
  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
deleted 10y ago
[deleted]
tchaffee 10y ago
I can get foo.author.title and foo.post.title no problem using Object.assign: Object.assign({}, { author: author }, { post: post }); Can you give a better example of where a reference to an instance is any different than copying an instance? EDIT: I fixed your example. https://jsbin.com/zamuqoropa/1/edit?js,console https://jsbin.com/zamuqoropa/1/edit?js,console EDIT 2: In fact, my Object.assign does exactly the same thing as your example of composition. And console.log(obj1.author === obj2.author); produces 'true'. https://jsbin.com/vafudizumo/1/edit?js,console https://jsbin.com/vafudizumo/1/edit?js,console Either you're doing composition wrong, or I'm not doing inheritance like you are claiming.

Lazare 10y ago

Object.assign({}, { author: author }, { post: post }); Yep, that's composition and it's identical to my composition example. Of course, you're not actually using Object.assign() to do anything; your code is 100% identical to just saying: {author, post}; Not that there's anything wrong with that...but do note that it's also the exact opposite of what Elliott is advocating for, not what he shows off in his code examples, not what his Stampit library does, etc. > Either you're doing composition wrong, or I'm not doing inheritance like you are claiming. Your first example (and Elliott's examples) are inheritance. Your second example is composition. The difference is enormous. Edit: Elliott says here[0] "Similarly, you can use `Object.assign()` to compose any number of objects together with last-in priority:" let ninjamouse = Object.assign({}, mouse, ninja); 1) That's not composition, that's inheritance. 2) That's the same as your first example, but fundamentally different than your second. He's trying to make a "ninjamouse" which has the properties and methods of both mice and ninjas, because it is a mouse and a ninja. (That's inheritance, and it's fragile for all the reasons inheritance is always fragile). Your second example makes an object that has both a mouse and a ninja. That's composition. "This technique is called concatenative inheritance" By absolutely no one ever. :) [0]: https://medium.com/javascript-scene/common-misconceptions-about-inheritance-in-javascript-d5d9bab29b0a#.jw2f0032r https://medium.com/javascript-scene/common-misconceptions-ab...

tchaffee 10y ago
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

deleted 10y ago

[deleted]

tchaffee 10y ago