4 ms·
> the "class" keyword was a huge mistake There is not a single fact proving that statement. People want to write Javascript in different ways, Javascript is no
by camus2 10y ago
> the "class" keyword was a huge mistake
There is not a single fact proving that statement. People want to write Javascript in different ways, Javascript is no less OO that it is FP. I don't see why one camp should be more privileged than the other.
> prototypal inheritance you will write cleaner code with fewer errors.
JS Classes use "prototype inheritance". compare that :
function Foo(){}
function Bar(){
Foo.call(this)
}
Bar.prototype = Object.create(Foo.prototype)
with that :
class Foo{}
class Bar extends Foo{}
There is absolutely no debate as to what is more readable, cleaner,easier to parse for IDE, and less error prone. ES6+ is considerably making writing JS easier and safer. There is very little reason today to deal with prototypes directly. And in strict mode, calling Foo or Bar without using new yields an error.
- tchaffee 10y agoEncouraging inheritance in the first place is the mistake. Using composition with Object.assign is far less fragile than inheritance. An article with concrete examples: https://medium.com/javascript-scene/master-the-javascript-interview-what-s-the-difference-between-class-prototypal-inheritance-e4cd0a7562e9#.ak2srgk4q https://medium.com/javascript-scene/master-the-javascript-in...
- camus2 10y agoThe point the OP was making that the class keyword was a mistake, not that inheritance was a mistake. This is an entirely different topic. Furthermore, Javascript classes make writing mixins AKA composition a breeze, compared to before: http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-classes/ http://justinfagnani.com/2015/12/21/real-mixins-with-javascr... This link is an excellent rebuttal to Eric Elliot article and how he achieve composition through copying by the way. So even if you like composition over inheritance, Javascript classes still allow you to write safer and clearer and cleaner code. Now you can do away with ugly factories and property copying. > Object.assign is far less fragile than inheritance You realize the using Object.assign means copying properties from object to object over and over and increase memory requirements in order to run a script. So my point still stands, there is not a single disadvantage introduced with the class keyword.
- tchaffee 10y agoThanks for the article, it's a long read that requires some thinking so I'll get to it tomorrow. In the meantime I'll put a Kyle Simpson chapter out there as a rebuttal to "there is not a single disadvantage introduced with the class keyword". He makes a good case that there is more than one disadvantage to the class keyword. https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/apA.md https://github.com/getify/You-Dont-Know-JS/blob/master/this%...
- Lazare 10y ago> Encouraging inheritance in the first place is the mistake. Yes. > Using composition with Object.assign is far less fragile than inheritance. Absolutely not. Object.assign is an example of inheritance, not composition, and it's just as fragile as the others. Eric Elliott is well known for calling "composition" what everyone else calls "multiple inheritance". See, eg: http://wsieroci.github.io/elliott/inheritance/composition/2015/12/28/inheritance-or-composition.html http://wsieroci.github.io/elliott/inheritance/composition/20... https://www.reddit.com/r/javascript/comments/3oy9c3/composition_vs_eric_elliott/?ref=search_posts https://www.reddit.com/r/javascript/comments/3oy9c3/composit... It's almost a running joke on the /r/javascript subreddit at this point.
- tchaffee 10y agoHow is Object.assign not a "has-a relationship"? From the first article you posted, this example of composition was given: { author: createAuthor(), posts: createPosts() } How is that different from this? Object.assign({}, author, post) In both cases you end up with an object that has an instance of an author and a post. What am I missing?
- Lazare 10y ago> In both cases you end up with an object that has an instance of an author and a post. But you don't; not even close. The first one is a has-a relationship; the object contains two references (`author` and `posts`), which presumably point to an instance of the Author class and a collection of instances of the Post class (or whatever). This is composition. The second is an is-a relationship; the object has the properties of the author and post objects copied over the top of it. There is now only one object (not three), and if we're lucky, it implements the interface contracts of both the Author class and the Post class. Consider if Author has a title field that contains their preferred prefix (Mr, Ms, Mrs, Dr), and Post has a title field that contains the subject line. With the first approach, we could do `foo.author.title` or `foo.posts[0].title`, using our references to the underlying Author or Post instances. With the second approach, we can do `foo.title` or...`foo.title`. Whups. We have no references, there is no underlying Author or Post instances; there's just a single object which is trying to inherit the behaviour of both the Author and the Post class, and failing. It's not a horrible way of implementing multiple inheritance in JS, but it's still inheritance. And in it's single inheritance form (`Object.assign({}, author)`) it's yields an identical result to normal prototypal inheritance or the class keyword. Edit: This becomes even clearer when you start to flesh out the examples. Eg, https://jsbin.com/kigewonepe/1/edit?js,console https://jsbin.com/kigewonepe/1/edit?js,console Note how obj2 has a `fullName` method (which only Author's do), because it is an author. Except note that it returns the wrong string when you run it, because obj is also a post. Where obj1 works correctly because it has an author and it has a post, without trying to be either of them. Composition over inheritance, just like the Gang of Four said. :)