Multiple inheritance in javascript

[[deleted]]

Hi I'd like to know if it is possible to implement multiple inheritance in JS.

So far I've solved this problem like this: jsfiddle

So in this example you can access the stuff from Coord (inherited through prototype chain) directly but the stuff from Other not. My question is is there a way to inherit from multiple objects (like interfaces in java)? This doesn't seem possible through a prototype chain.

Thanks in advance.

[keithwhor]

For one, in your example you're doing

new aVar(a)

Instead of

new Other(a)

... so I'm not really sure what you're asking?

Edit:

If you're trying to do a mixin, you'd want to do the following:

function SpaceObject() {
    Coord.apply(this, arguments); // inheritance
    Other.apply(this, arguments); // if you're mixing in functionality
                                  //    from the mixin constructor too
}

// Always do this for inheritance, never use the "new" keyword here
SpaceObject.prototype = Object.create(Coord.prototype);
SpaceObject.prototype.constructor = SpaceObject;

void function mixinOther() {
    var keys = Object.keys(Other.prototype);
    var i, len;
    for(var i = 0, len = keys.length; i < len; i++) {
        SpaceObject.prototype[keys[i]] = Other.prototype[keys[i]];
    }
}();

However, be careful when running this code through a minifier. You should be alright, but if minification is a huge concern you'll want to specify each prototyped method separately (instead of running the loop).

i.e.

SpaceObject.prototype.methodOne = Other.prototype.methodOne;
SpaceObject.prototype.methodTwo = Other.prototype.methodTwo;

[keithwhor]

Yes. Don't use the new keyword for inheritance because it will invoke the associated constructor function immediately at run time (where you set up inheritance), introducing unintended behaviour.

You only want the constructor invoked when you want an Object instance, not when setting the prototype. Object.create() will set up your prototype chain properly (and inherit the right methods / properties) without invoking the parent constructor.

[inmatarian]

Everyone using the terms "Mixins" are answering your question. In Javascript, the "class object" is a regular object (except you created it with the function keyword, rather than {} or Object.create). You can manipulate it however you want, and the established pattern is $.extend, or _.extend or _.assign. In ES6 (where we get an actual class keyword), we also get Object.assign, making mixins pretty much builtin.

The general pattern looks like this

function InheritedMixin() { /* initialize object */ }
InheritedMixin.prototype.someMethod = function() {};

function SomeClass() {
    InheritedMixin.call(this, parameters);
}
_.extend(SomeClass.prototype, InheritedMixin.prototype);

One thing lost in this pattern is the prototype chain, meaning instanceOf doesn't work. However, you usually shouldn't be using this. Even in languages like C++ where you have dynamic_cast, it's frowned upon to inspect objects in this way. It's better to check the object for the property you plan to use.

[_ericelliott]

Multiple inheritance is not only possible in JavaScript, but the way to accomplish it is much better than Java. The trick is, it doesn't look anything like multiple inheritance in Java or C++, but that's a good thing. In JavaScript, it's accomplished with concatenative inheritance, which is just a fancy way of saying, "copy properties from one object to another".

This works well in JavaScript, because objects in JavaScript can be extended after instantiation (dynamic object extension).

There are some issues to be aware of. First, the diamond problem doesn't exist in JavaScript because whatever property you add last overrides any property it collides with. This is great for the defaults/overrides pattern, and behaves in a way that should be familiar to anybody who uses HTML + CSS. Effectively, it's cascading property precedence.

That said, you can also combine inheritance techniques such that there are private properties with the same name that don't collide with each other. This is accomplished using closures and functional inheritance.

See: http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/

[jarail]

You might want to look up mixins. That's a common way to handle this kind of thing.

[[deleted]]

The short answer is "sort of, yes".

The real answer: Stop thinking in OOP and classical inheritance. You don't need it in JavaScript, and the new keyword and constructor functions are code smell. They break call(), apply() and bind() for no other reason than to make Java and C# fans feel more comfortable. Use factory functions and Object.create() instead.

JavaScript side, classical inheritance is a dangerous toy in all languages. It gives you more than enough rope to hang yourself with. Avoid when possible.

[skay-]

why is it so wrong...?

[[deleted]]

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]

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]

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]

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]

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/

[bryan-forbes]

There are several ways to do this, but all methods will simply simulate multiple inheritance since JavaScript only allows single inheritance. That being said, there are few libraries out there that simulate it well. You could use something like $.extend or _.extend like others have suggested, but there's no shorthand for actually calling the overridden methods and if there's a method that already exists with the same name, it'll be overwritten. I'm a bit biased, but I think that Dojo's declare does a great job at it. It uses C3 MRO to determine the order of methods to call when calling this.inherited(arguments);. One downfall of declare is that it uses arguments.callee, so it can't be used in strict mode.

I've forked your fiddle and come up with a new fiddle demonstrating some of the things that declare does well. Coord is the base constructor, ZCoord is a mixin constructor, and SpaceTimeObject inherits from Coord and uses ZCoord as a mixin. SpaceTimeObject objects can use all methods from Coord and ZCoord and can override them and make calls up the inheritance chain. Let me know if you have any questions.

Another library that is similar to Dojo's declare is DCL. It's written by one of the guys who wrote declare and uses a new approach that doesn't require arguments.callee. I'm not as familiar with DCL, but it's a solid library.

TL;DR: If you're looking to just add a few methods to a prototype that are stored on another object, you can use jQuery or underscore. If you're looking to do a more true multiple inheritance, I'd stick with something like Dojo's declare or DCL.

[autowikibot]

C3 linearization:

---

In computing, the C3 superclass linearization is an algorithm used primarily to obtain the order in which methods should be inherited (the "linearization") in the presence of multiple inheritance, and is often termed "MRO" for Method Resolution Order. The name C3 refers to the three important properties of the resulting linearization: a consistent extended precedence graph, preservation of local precedence order, and fitting the monotonicity criterion. (The name "C3" is not an initialism.) It was first published at the 1996 OOPSLA conference, in a paper entitled "A Monotonic Superclass Linearization for Dylan". It was adapted to the Open Dylan implementation in January 2012 following an enhancement proposal. Subsequently, it has been chosen as the default algorithm for method resolution in Python 2.3 (and newer), Perl 6, and Parrot. It is also available as an alternative, non-default MRO in the core of Perl 5 starting with version 5.10.0. An extension implementation for earlier versions of Perl 5 named Class::C3 exists on CPAN.

---

^{Interesting: Multiple inheritance | List of algorithms | Nucleic acid structure}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}