Skip to content

Similar ideas #2

@trusktr

Description

@trusktr

I wrote about this too, without knowing about the existence of this repo until now. Here's a similar idea I wrote about partial classes,

https://es.discourse.group/t/proposal-idea-partial-classes-mixins/2445

But various people in TC39 are very against this type of patterns mainly from personal preference, which may unfortunately make it difficult for this to become reality unless personnel in TC39 change (f.e. more members with a bias towards other patterns, or people change careers and skew that bias with absence of theirs, or etc). F.E. some people there (I won't name anyone) prefer functional programming over classes, yet they ironically project their opinion very strongly as to how classes should be despite being against them.

Here's a prototype I created of a runtime helper for multiple inheritance that looks like this:

class One {
  one() {...}
}

class Two {
  two() {...}
}

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

const o = new Three()

o.three() // calls one and two

console.log(o instanceof One) // true
console.log(o instanceof Two) // true
console.log(o instanceof Three) // true

Initial impl in multiple.ts and unit tests multiple.test.ts.

This very much employs the idea that a class does not need to know if it will be used in multiple inheritance or not. F.E. just import an EventEmitter class from anywhere, and mix it into your class, without the EventEmitter author having to explicitly make that class be a mixin class.

The way multiple works is it has a main prototype chain, then separate chains for the second/third/etc classes, using Reflect to properly remap target and receiver. Basically we end up with a prototype chain tree. Classes the extend multiple classes that extend multiple classes form a tree. Member lookup happens in order classes are passed to multiple(), the first match wins (breadth first tree order). It's a concept, I haven't had time to add features like method disambiguation when names are the same, etc.

The Reflect trick basically maps to multiple class instantiations from a single root instance.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions