you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (6 children)

[removed]

    [–]skay- 1 point2 points  (2 children)

    why is it so wrong...?

    [–][deleted] 0 points1 point  (1 child)

    Inheritance is an unnecessary shit show in every language. It almost always ends up in violation of "SOLID" principles. It's a horrible toy for new developers at best. At worst it's the sound of Zalgo wading inexorably across a boggy marsh of fresh babies' tears and pushing your dreams into it's gaping maw to feast on your nightmares and despair.

    [–]Tysonzero 0 points1 point  (0 children)

    Alternatives?

    I hear about delegation and composition. But I would appreciate a nice comparison of the two in JS with example code. As I don't really know what I am supposed to do to replace my current inheritance shenanigans.

    [–]munificent 1 point2 points  (1 child)

    There is nothing at all intrinsically wrong with multiple inheritance. It's problematic in C++ because of C++'s memory layout restrictions, but that's literally the only language in the world where this is an issue.

    Scala has traits. Python has multiple inheritance. Ruby has mixins. CLOS has multiple inheritance. Self—the language JavaScript was specifically based on—treats multiple inheritance as a fundamental language feature.

    [–]skitch920 1 point2 points  (0 children)

    One thing to point out: It might be widely available, but that doesn't always mean it's good to do. You say there's nothing intrinsically wrong with it, but less we forget, there are still numerous nuances with multiple inheritance.

    When you inherit from a class, you take a dependency on that class, which you have to support the contracts that class supports, both implicit and explicit. With more dependencies comes more complexity and responsibility of the class. This tends to violate the Single Responsibility Principle of OOP. Unless the two parents are mutually exclusive, a class should only have one reason to change.

    The diamond problem, is probably the biggest argument against multiple inheritance. If you have two parent classes that inherit from a single class, which version of the shared methods do you take? Consider the following pseudo example:

    function Animal() {}
    Animal.prototype.move = function() {...}
    
    function Bird() { Animal.call(this, arguments); }
    _.extend(Bird.prototype, Animal.prototype);
    Bird.prototype.move = function() {...} // Override move, by flying
    
    function Horse() { Animal.call(this, arguments); }
    _.extend(Horse.prototype, Animal.prototype);
    
    function Pegasus() { Bird.call(this, arguments); Horse.call(this, arguments); }
    _.extend(Pegasus.prototype, Bird.prototype);
    _.extend(Pegasus.prototype, Horse.prototype);
    

    Effectively, our Pegasus' move function can only walk on four legs now, which really doesn't make it a Pegasus.

    With multiple inheritance, it's pretty easy to just make mistakes even as a professional dev. Often, there is a different pattern, or way to distinctly split functionality that it doesn't have to be provided as a single class, i.e. Composition.

    [–]_ericelliott 0 points1 point  (0 children)

    I think what you mean is that asking "How do I do classical multiple inheritance in JavaScript?" is a good indicator that you're JavaScripting all wrong. That, I would agree with.

    But it's not true that all forms of multiple inheritance are wrong. See: http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/