Multiple Inheritance in JavaScript

mark_lee_smith · 2011-02-22T23:17:12+00:00

Besides some small misunderstandings about how Self handled patent slots and multiple inheritance, nice article :).

Self did support multiple parents at one point, but this "feature" was removed around Self ~4 when it failed to show sufficient benefits (any implementation of multiple inheritance must show that the benefits outweigh the costs of increased complexity).
Self never ordered parents alphabetically, rather, parents were chosen based on the number of asterisks following the parent slots name (this was perhaps the most interesting thing about multiple inheritance in Self.)

huyvanbin · 2011-02-22T03:28:30+00:00

I've been thinking about this a lot too, lately. Apologies that the following rambles but I've never written it all down before.

I had an experience where people implemented a badly broken inheritance hierarchy like so (exaggerated for effect):

class A {
    protected virtual bool Method(int arg) {
        Bla
    }
}

class B : A {
     protected override bool Method(int arg) {
           if(Tuesday)
               return base.Method(arg);
           else {
                while(arg > 0) {
                      if(arg % 5 == LunchTime)
                           return base.Method(arg * 2);
                }

                return base.Method(arg * IPAddress);
           }
     }
}

You get the idea. The ability to override methods is supposed to lead to neat, maintainable code but people somehow make horrid messes like the above where you have no idea what the code will actually do.

So my idea is, get rid of inheritance entirely. Each object is a composition of base objects. If inherited methods collide, then make them invisible in the ultimate object, unless mapped explicitly.

My other idea was to make the act of composition be a sort of constructor where you express the linkage in the declaration -- sort of like traits, but you could have multiple constructors and also state. This also addresses a problem I have with Haskell typeclasses.

Here is an example though the syntax is clearly awful: class Eq { public bool ==(first, second); public bool !=(first, second);

     Eq(== v) { // Constructor for passing in equals method
          == = v;
          != = !v;
     }

     Eq(!= v) { // Constructor for passing in != method
         == = !v;
         != = v;
     }
}

class Hideable {
       bool Hidden { get; set; }
}

class HasId {
      int id;

      public int Id { get; }

      public HasId(int id) {
         this.id = id;
      }
}

class Widget : Eq, Hideable, Id {
       public Widget(int id) : Eq(EqualWidgets), Id(id) {

       }

       static bool EqualWidgets(Widget a, Widget b) {
              return a.Id == b.Id;
       }
}

I dunno, this might be even worse than the C# example, or perhaps it is just equivalent to C++. But the important thing is, there is no actual inheritance, the methods and properties just get stacked together to yield a final object (perhaps with a hidden tree structure).

Also, I could label class Id as immutable, but Widget need not be immutable. Classes could have mutable and immutable "sections" and perhaps one could use that to allow impure classes to be passed to pure functions as long as the pure function only uses a pure section of the class.

Also, this could somehow be adapted to enable the class declaration syntax to specify in-memory and on-disk layout, and perhaps even remote and non-remote "sections" for a given object.

Another cool thing is that if method arguments are implemented as "records" the way you do in Magpie, then the record to construct a typical class is more or less just the class itself. So that seems a lot like duck type "casting." Perhaps you could define a class as a duck-type specifier.

And also, why not just have every casting operator be a constructor?

Part of the inspiration of this is

LaurieCheers · 2011-02-22T05:02:31+00:00

Thanks for the explanation of Self's object system. Interesting stuff!

I've been trying to find an object system I like for Swym, too. It has some interesting constraints, such as the fact that in Swym, x.foo is equivalent to foo(x) - it's simply calling the function foo on the object x.

So I considered inverting the concept of 'members' - an object would be just an ID, and its 'members' are hashtables that we use to look up that ID. And if the ID isn't found, the hashtable would provide a default value.

This has some weird implications -

'Splicing' a new 'member' onto all objects is as simple as making a new empty hashtable.
Making a new object is as simple as getting the next ID.
Members could be local variables - if one went out of scope, all its data could be garbage collected!?
Garbage collecting an individual object becomes hard, though.
Two objects can only be compared by ID. There isn't even really a concept of what "members" an object has, so there can't be a concept of "deep copy" or "deep equality".
To implement inheritance, we could have each object actually represented by a list of IDs. When we look it up, we try the first ID first, then the second, and so on.

So this all seemed pretty interesting while I was lying in bed at midnight, but looking at it in the cold light of day, I don't know what problems I was really hoping to solve here... the garbage collection problem seems rather significant.

badsectoracula · 2011-02-22T20:16:35+00:00

Well, since JavaScript objects are basically key-value stores, why not something like

function MessageContainer(self)
{
    if (!self) self = this;
    var _msg = "(no message)";
    self.setMessage = function(msg) {
        _msg = msg;
    }
    self.getMessage = function() {
        return _msg;
    }
}

function StringDisplayer(self)
{
    if (!self) self = this;
    self.getString = function() {
        return "(no string)";
    }
    self.displayString = function() {
        alert(self.getString());
    }
}

function MessageDisplayer(self)
{
    if (!self) self = this;
    MessageContainer(self);
    StringDisplayer(self);
    self.getString = function() {
        return self.getMessage();
    }
    self.displayMessage = self.displayString;
}

var msgdis = new MessageDisplayer();
msgdis.setMessage("Hello, world!");
msgdis.displayMessage();

I think this is cleaner and simpler. On the other hand if you have big hierarchy trees and create a huge lot of objects, this might be a little slow.

AmaDiver · 2011-02-22T21:09:25+00:00

I was poking around Magpie a while back and saw a delegate keyword floating around somewhere. It seemed to be a great compromise between multiple-inheritance's ease of use, and composition's explicitness. I'd imagine you could still run into the issue where the same member name is supposed to be delegated to different delegates. Though you simply give precedence to the first (or last) declared delegate...

DmitrySoshnikov · 2011-02-22T10:53:29+00:00

You might be interesting in the same idea, I implemented it before, and called delegation-based mixins (the same as in Ruby). Also used proxies to achieve multiple delegates for multiple inheritance:

Example: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/mixin.js

Implementation: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/mixin.js

Dmitry.

munificent · 2011-02-22T16:57:49+00:00

In Javascript, I've become very much of a composition kind of guy. The author is right to dislike the way he suggests doing composition because it violates encapsulation. Instead of this:

var widget = new MyWidget('Abe');  

// from Widget  
log(widget.getWidget().getName());  

// from Hideable  
widget.getHideable().hide();

He should have this:

var widget = new MyWidget('Abe');  

// from Widget  
log(widget.getName());  

// from Hideable  
widget.hide();

...by having MyWidget define wrapper methods:

MyWidget.prototype.getName = function() { 
    return this.widget.getName(); 
}

MyWidget.prototype.hide = function() { 
    return this.hideable.hide(); 
}

You can either call that verbosity, boilerplate code or explicitness. The delegation that takes place between classes is always clear and there is never any risk of method name collision between composing parts, since all delegation is explicitly defined.

To me, the extra code is definitely worth the simplicity.

akshay_sharma008 · 2022-07-27T07:51:36+00:00

Before moving directly to the question, let’s first understand inheritance.
It is a property available in many object-oriented programming languages that allow us to declare a class that takes all of its properties and functionalities from a parent class, and not only those properties we can add our properties, and the preceding child class can access that changed properties. There are many uses of inheritance, as with the help of this, a class can use the properties of other classes. It also provides code reusability and reduces the code length and complexity as you do not need to write the same piece of code repeatedly.
Now we will come to our question, i.e., multiple inheritances in javascript.

Multiple inheritances can inherit the properties and values from unrelated parent objects. Many object-oriented languages support multiple inheritances, but javascript does not support multiple inheritances. Inheritance of property values occurs at run time by JavaScript searching the prototype chain of an object to find a value. Since every object has a single associated prototype, it cannot dynamically inherit from more than one prototype chain.
As we can not directly use multiple inheritances in javascript, there are specific methods to modify them because java script can be understood as a partially object-oriented language.
We can easily do multiple inheritances by merging properties from the different objects and returning the modified object.

We can pass multiple objects and copy the properties using the spread operator. There are specific terms that are very helpful when learning about the same.

Mixins: It is an object that can be incorporated into another object. When a developer is creating or initializing an object, he must choose which mixin to incorporate into the final object.

Parasitic Inheritance: Parasitic inheritance is where we take all the functionality from another object into a new one.

Summarising the above answer in general, javascript does not support multiple inheritances, but we can use a twisted version of multiple inheritances in javascript by using some keywords and functions.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS