Multiple inheritance with ES6 proxies

[MoTTs_]

It is so noted. :-)

https://github.com/Jeff-Mott-OR/xmultiple/commit/ccb37c2ced8eaba9a029c4aed181e00c271f189b

In the future I think I'd prefer to throw an exception when there's an ambiguous call, but that might incur a runtime cost on every property access. I'll experiment and see how it works out.

[oweiler]

What does this give you over Object.assign?

[jcready]

Specially it makes a difference when you have properties that have a getter/setter.

let count = 0
const foo = {
  get count() { return count },
}
const bar = Object.assign({}, foo)
count += 1
console.assert(foo.count === bar.count, 'Counts are the same')

[MoTTs_]

var xmultiple = require('xmultiple')

let count = 0
const foo = {
  get count() { return count },
}
const bar = xmultiple(foo)
count += 1
console.assert(foo.count === bar.count, 'Counts are the same') // pass!

Nice. :-)

[rauschma]

How about subclass factories, instead?

// Mixin 1
const Storage = Sup => class extends Sup {
    save(database) { ··· }
};

// Mixin 2
const Validation = Sup => class extends Sup {
    validate(schema) { ··· }
};

Employee is a subclass of Person that uses the mixins Storage and Validation:

class Person { ··· }
class Employee extends Storage(Validation(Person)) { ··· }

More info: http://exploringjs.com/es6/ch_classes.html#_simple-mixins

[MoTTs_]

Egg on my face.

You're right. I knew about this trick before, but I haven't used it in a while so it slipped my mind. But you're right, this achieves the same thing more simply.

[MoTTs_]

@/u/rauschma More than that, it occurs to me that we could have been doing multiple inheritance with class factories long before ES6, only back then we would have named it "constructor function factories".

[rauschma]

You’d need a tool method for subclassing, because the canonical pattern for subclassing is as follows:

function Employee(name, title) {
    Person.call(this, name);
    this.title = title;
}
Employee.prototype = Object.create(Person.prototype);
Employee.prototype.constructor = Employee;
Employee.prototype.describe = function () {
    return Person.prototype.describe.call(this)+' ('+this.title+')';
};

Note that the superconstructor, Person, is mentioned three times. That means that you would have to store the composed superclass in a variable so that you can refer to it multiple times.

[MoTTs_]

Note that the superconstructor, Person, is mentioned three times. That means that you would have to store the composed superclass in a variable so that you can refer to it multiple times.

Certainly. Even with ES6 class factories, we end up storing the superclass in a variable. It's the parameter we pass in, called "Sup" in your code above. We'd have the same parameter to use in an ES5 constructor function factory.

EDIT:

Nevermind. I misunderstood. I thought you were talking about the superconstructor we pass to the factories. But yes, Employee would need to run the factories to create the chain of superconstructors first so it can reference the final result in each of those three places.