I've already invested significant time in trying to shed more light on this topic. In my book, in that video, in blog posts, and now here. Take your pick.
The cliff notes for the lazy (with sketchnotes!) What I want to say has been said many times before: class inheritance causes problems that do not even need to exist in JavaScript. The Gang of Four considered this so important, that they made it one of two principles which are a central theme in the "Design Patterns Book"... but even the first principle is related, so I'll start there: "Program to an interface, not an implementation", If you need a reference to the parent class in the implementation of the child class (the part that is expressed in the code of the language user), that is a violation of that principle. That is why "super" is considered to be a code smell. http://martinfowler.com/bliki/CallSuper.html and "Favor composition over class inheritance." The reason for that is that deep inheritance hierarchies are too tightly coupled (child to parent), and too dependent on parent implementation (see above). These problems cause code arthritis as projects mature and you begin to inherit from sub-classes. Eventually that leads inevitably to brittleness, and the famed gorilla banana problem. "The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - Joe Armstrong, "Coders at Work" Debugging such structures can be challenging. Changing them can force large, time consuming refactors, and in some cases, complete project rewrites. I've seen this happen in the real world again-and-again. Mostly in C++ and Java. When I came to JavaScript in the late 90's, it seemed like there was some relief from that. I just didn't see things like that happening very much... despite being involved in JavaScript-heavy serious applications for almost all of my career.... Until Backbone caught on and made .extend() the defacto way to reuse code in a very popular library. Then suddenly everybody started subclassing in JavaScript like it was a brand new idea. Then I started seeing those problems I thought we'd left behind resurface in real-world applications for companies producing apps with millions of users. Serious problems with major code bases in the wild... because people were running with a pattern that was never a good idea. It is a particularly bad idea in JavaScript primarily because using it is actually harder than using the better alternatives that already exist natively (notably a single prototype (not a userland chain), and dynamic object extension, which makes mixin implementations trivial). My argument is that it should *stay harder to implement*. Not only do we not need class, what we have is much easier, much more flexible, and dramatically less problematic. Some great alternatives to classes include modules (particularly those that export functions), factory functions, object literals, Object.create(), and simple dynamic object extension. You can combine all these and create some neat sugar that doesn't involve single-ancestor inheritance, tight coupling between parent and child, and encouraging users to think in a broken paradigm. More reading (if you can find the time): Sketchnotes - http://instagram.com/p/Z6ocvmRJSf/ Slideshow source - https://github.com/dilvie/fluent-prototypal-oo Blog post - http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/ Different author, similar message - http://davidwalsh.name/javascript-objects (3 parts) - Eric Elliott On Fri, Jun 28, 2013 at 11:40 AM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Fri, Jun 28, 2013 at 11:31 AM, Eric Elliott <e...@ericleads.com> wrote: > > I'm not here to discuss the mechanics of what class does. I'm just > saying we > > shouldn't do it in the spec. There are better alternatives that pose less > > threat to the JavaScript ecosystem. > > > > A handful of libraries and JavaScript authors twisting prototypes to make > > them less useful is one thing. Getting a blessing from on-high for > people to > > teach that it's "how to do inheritance in JavaScript" in teaching > materials > > is quite another thing. > > It is how you do (single) inheritance in JS. In your OP, you say "I > think we should wait for some patterns to gain a foothold in the > wild". Single inheritance via prototype chains is an immensely > popular pattern for this kind of thing. You do qualify your statement > by saying we should wait for *good* patterns, but single inheritance > is perfectly good for some things, and adequate for quite a bit else. > There are certainly better patterns, but none of them have gotten wide > traction yet. We definitely want to pursue something like mixins in > the future, but in ES6 we purposely went for a "maximally minimal" > class syntax, adding as little as possible while still achieving the > readability and usability gains of having a dedicated syntax. > > For example, when we come up with a good mixin pattern, adding it to > the class syntax is as easy as doing "class Foo mixin Bar, Baz, Qux > {...}". No clash with "extends"; it just slots in cleanly. > > > My arguments (and a few suggested alternatives) are in the video. > > > > If you're going to blow off what I have to say about it because you don't > > have time to watch a video, I guess the conversation is over. =) > > In our private conversation, I just asked for a text version, as it's > several times faster to read text than listen to a talk. It would > likely take you roughly as much time to write out the points you want > us to take from the video as I, individually, would save by being able > to read them instead of having to watch the video. When multiplied > over the whole mailing list (or at least the people interested enough > in this thread to care), the balance of time is clearly on the side of > "just spend the time writing out what you want to say". > > ~TJ >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
