Should mixins be inheritance-based?

[zenparsing]

The inheritance-based approach to mixins has some odd side-effects:

• It's a little unclear how multiple mixins ought to work
• It's impossible to use mixins to build up a single "base" class

Usually I want to use mixins to simply "fill out" a bunch of features on the concrete class. In other words, I want to copy properties from the mixin source to the mixin target.

What would the tradeoffs be for an alternate design where class C with ... copies properties from the source, rather than building up an inheritance chain?

Thanks!

[canonic-epicure]

I think this point

It's a little unclear how multiple mixins ought to work

Is exactly the opposite with inheritance-based mixins (I'm strong proponent of those)

It is very clear, how multiple inheritance-based mixins combines together. And it is very unclear how they combine for copying-based mixins. Here's why:

Inheritance-based mixins, as follows from their name, just performs inheritance. This is a simple, intuitive concept, everybody understands very well. If you combine several mixins - thats just long inheritance chain, thats all. Again, the intuition, developed from the years of work with single-class inheritance answers all questions.

For copying-based mixins there's no such intuition to re-use. You need to write some specification that will define all edge cases:

• What will happen if 2 or more mixins defines the method/property with the same name? Which one will "win"? Only 1 method wins or all of them?
• In what order the constructors of mixins are called?
• If some method is defined in the mixins and in the class itself - what is the order of calls for super chain?
• What will happen if in one mixin some property is private, but in another public? etc, etc