# Multiple inheritance (not class-factory mixins). Will it ever be a language feature?

**URL:** <https://es.discourse.group/t/multiple-inheritance-not-class-factory-mixins-will-it-ever-be-a-language-feature/176>\
**Category:** 💡 Ideas\
**Created:** [December 28, 2019, 11:24pm UTC](https://es.discourse.group/t/multiple-inheritance-not-class-factory-mixins-will-it-ever-be-a-language-feature/176 "2019-12-28T23:24:17Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![trusktr](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/trusktr/32/183_2.png) [@trusktr](https://es.discourse.group/u/trusktr)\
**Post date:** [December 28, 2019, 11:24pm UTC](https://es.discourse.group/t/multiple-inheritance-not-class-factory-mixins-will-it-ever-be-a-language-feature/176/1 "2019-12-28T23:24:17Z")

</div>

I wonder if we can do it.

I don't like class-factory mixins, because they require wrapping classes in functions. Therefore, one can not import a 3rd-party class and compose it.

I've implemented a `multiple()` inheritance helper tool using `Proxy` under the hood. It works like this:

```javascript
import {multiple} from 'lowclass'

class One {one() {}}
class Two {two() {}}
class Three {three() {}}
class Three extends multiple(One, Two, Three) {
  four() {
    this.one()
    this.two()
    this.three()
  }
}

```

That's a simple example, but you start to get the idea.

Implementation(s) are in [lowclass/multiple.ts](https://github.com/trusktr/lowclass/blob/ac6312111dc4a1f33cb21e4c5c02a7e3068f05a3/src/multiple.ts), and basic initial tests in [lowclass/multiple.test.ts](https://github.com/trusktr/lowclass/blob/ac6312111dc4a1f33cb21e4c5c02a7e3068f05a3/src/multiple.test.ts).

(Curious to know if you have any ideas on how to improve it!)

There are still a bunch of cases I need to add to the tests and account for in the implementation, but it works for simple use cases like the following:

Suppose we have the following code:

```javascript
import {ExternalClass} from 'third-party-library'

class OurClass extends ExternalClass { ... }

```

Then, imagine that we want to add `EventEmitter` functionality to `OurClass` so it will emit events. We can do this simply:

```javascript
import {ExternalClass} from 'third-party-library'
import {multiple} from 'lowclass'
import EventEmitter from 'events' // from Node.js

class OurClass extends multiple(ExternalClass, EventEmitter) {...}

const o = new OurClass
o.on('some-event', () => {...})

```

This is better than class-factory mixins for two main reasons (among others):

- all functionalities are written as plain `class`es. No wrapper-function boilerplate code. Simple.
- import any 3rd-party `class`es and mix and match them. This is impossible with class-factory mixins.

TODOs:

- per-constructor args. This will give the ability to pass specific args to each constructor that a subclass extends from.
- statics: I haven't needed static inheritance yet so I haven't implemented that yet, but inevitably it'll be needed, and that's easy to implement.
- Use `Symbol.hasInstance` to make `instanceof` work.
- Diamond problem, or similar: give the ability to specify which super methods to call when there are name collisions in a hierarchy.

I am already familiar with [proposal-mixins](https://github.com/justinfagnani/proposal-mixins), but I don't like it because it's syntax for class-factory mixins. It means that we must explicitly choose between writing a `class` or writing a `mixin`. We get the same problem with 3rd-party code: we don't control the source, so we can't just convert a `class` into a `mixin`.

How would true multiple inheritance syntax look like?

Here's an idea, converting the same example from above:

```javascript
import {ExternalClass} from 'third-party-library'
import EventEmitter from 'events' // from Node.js

// simple syntax
class OurClass extends ExternalClass, EventEmitter {...}

const o = new OurClass
o.on('some-event', () => {...})

```

I'd also need to iron out syntax for calling specific constructors with specific args and calling specific methods when there are name collisions.

Maybe this can eventually turn into a proposal, but I'd first like to iron out the behavior, and I'd also like to implement it in native code (fork Firefox, if I get that far).

---

<div class="post-metadata">

**Author:** ![claudiameadows](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/claudiameadows/32/126_2.png) [@claudiameadows](https://es.discourse.group/u/claudiameadows)\
**Post date:** [December 31, 2019, 6:08am UTC](https://es.discourse.group/t/multiple-inheritance-not-class-factory-mixins-will-it-ever-be-a-language-feature/176/2 "2019-12-31T06:08:39Z")

</div>

Few major questions here:

1. How do you manage reflection? With the current system, you can do `Object.getPrototypeOf(object)` and get the prototype, but how do you do that with multiple inheritance?
2. How do you set up that inheritance chain with plain objects? JS internally is entirely prototype-based and classes can be entirely desugared to prototypes + `new.target` + weak maps for private fields, and multiple inheritance has to interop with that somehow.
3. What would `Object.getPrototypeOf(OurClass.prototype)` return and what would `Object.setPrototypeOf(OurClass.prototype, foo)` do?

---

<div class="post-metadata">

**Author:** ![raulsebastianmihaila](https://avatars.discourse-cdn.com/v4/letter/r/dc4da7/32.png) [@raulsebastianmihaila](https://es.discourse.group/u/raulsebastianmihaila)\
**Post date:** [January 3, 2020, 7:28am UTC](https://es.discourse.group/t/multiple-inheritance-not-class-factory-mixins-will-it-ever-be-a-language-feature/176/3 "2020-01-03T07:28:51Z")

</div>

Please see [https://www.npmjs.com/package/smart-mix](https://www.npmjs.com/package/smart-mix)  
It works with classes and without classes. Works with public and private data (that can be shared between mixins). See the ' Advantages over other mixin approaches' section in the README.

---

<div class="post-metadata">

**Author:** ![trusktr](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/trusktr/32/183_2.png) [@trusktr](https://es.discourse.group/u/trusktr)\
**Post date:** [June 6, 2020, 8:57am UTC](https://es.discourse.group/t/multiple-inheritance-not-class-factory-mixins-will-it-ever-be-a-language-feature/176/4 "2020-06-06T08:57:05Z")

</div>

> [@claudiameadows](#):
>
> `Object.getPrototypeOf(object)` and get the prototype, but how do you do that with multiple inheritance

I didn't plan on doing that. With the current API, we just make instances, read or write properties, and call methods. The end use case is not for meta programming, but for regular scenarios (we `new` something, then use the APIs, or we extends from the classes).

However, I think it would be possible to monkey patch `Object.getPrototypeOf` to return a Proxy that can do the same branched property lookup, similar to what the `multiple()` implementation does internally.

> [@claudiameadows](#):
>
> How do you set up that inheritance chain with plain objects?

I wasn't planning on doing that either. But maybe we can we can invent something like `Object.setPrototypes()` which accepts an array of objects, and internally create a Proxy to do the branched property lookup.

Maybe with such a new feature as multiple inheritance, we don't have to allow certain things to be doable. But if we did, we'd have to imagine some new APIs, like

```js
Object.getPrototypesOf(obj) // return an array which are the children in the tree of prototypes for the current prototype.

```

We would just need to think of it as a tree structure, while staying backwards-compatible with prototype chains.

---

<div class="post-metadata">

**Author:** ![claudiameadows](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/claudiameadows/32/126_2.png) [@claudiameadows](https://es.discourse.group/u/claudiameadows)\
**Post date:** [June 10, 2020, 10:39pm UTC](https://es.discourse.group/t/multiple-inheritance-not-class-factory-mixins-will-it-ever-be-a-language-feature/176/5 "2020-06-10T22:39:36Z")

</div>

I do separately want to throw out there that multiple mutable prototypes are a massive PITA to optimize for thanks to all the complicated dependency tracking. You'd have to turn single-item fields into full arrays, and you'd have to only conditionally do this. Also, if you modify a prototype, it now doesn't just follow one tree, but several trees, and it also has to detect if other trees have that property during that tree walk (as to not modify overridden methods). And obviously, cycle detection would go from walking a list to a full tree traversal, something I don't see a lot of engines being happy with. The biggest concerns beyond how to retrofit it into the language are around performance, not semantics (which have been well-studied for years, in large part due to C++ and Python).

Also, keep in mind things like mixins do fulfill 90% of the use case of multiple inheritance, and implementing that only takes at most 10% of the effort.

---

<div class="post-metadata">

**Author:** ![trusktr](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/trusktr/32/183_2.png) [@trusktr](https://es.discourse.group/u/trusktr)\
**Post date:** [July 27, 2020, 10:30pm UTC](https://es.discourse.group/t/multiple-inheritance-not-class-factory-mixins-will-it-ever-be-a-language-feature/176/6 "2020-07-27T22:30:01Z")

</div>

```javascript
class Foo extends One, Two, Three {
  // ...
}

```

would be so nice!

Maybe instead of relying on prototypes (a tree of them) for the whole class definition, the above could behave as

```javascript
class Foo extends One { ... }

```

while for any properties that are not found on `this` the lookup could simply delegate to instances of `Two` and `Three`.

`this` would be instance of `Foo`, and the other two instances of `Two` and `Three` would not directly be directly referenceable by the end user, and accessing props on `this` (instance of `Foo`, but delegating to other instances) would be the only way to access props.

If we did it this way, I think it would mean that engines could optimize each instance of a class the same way they already do, and they'd have a hierarchy (tree) of lookup tables for props/methods.

Wdyt?

---

<div class="post-metadata">

**Author:** ![trusktr](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/trusktr/32/183_2.png) [@trusktr](https://es.discourse.group/u/trusktr)\
**Post date:** [January 17, 2022, 3:32am UTC](https://es.discourse.group/t/multiple-inheritance-not-class-factory-mixins-will-it-ever-be-a-language-feature/176/7 "2022-01-17T03:32:22Z")

</div>

I'd like to add that, in theory, with the above described approach, it is possible that all optimizations an engine could do on classes written in a fully static optimizable way for single-instance instances would carry over to multi-instance instances. Each instance in the hierarchy would have individually optimized classes.

If all instances in the hierarchy have essentially a static lookup table (when code does not do anything deoptimizing like modifying prototypes or adding/removing descriptors, etc), then the worst case would be that the engine would have to lookup on multiple tables, one per instance (one per class), but the best case is that the engine could combine tables into one.

This is theoretical of course, and I think there's still much optimization work to do even on our current single-inheritance classes from what I can tell.