Recap our design discussions - some form of multiple inheritance is a must. Java/C# class vs interface is way too limiting to model real world problems. There are two practical approaches we have proposed:
class-only true multiple inheritance
mixin multiple inheritance
In class-only inheritance there is only classes, and any class can extend one or more classes. In mixin inheritance we make a distinction between classes vs mixins. Basically a mixin is like an interface in that a class can extend only one other class, but mixin zero or more mixins. However unlike an interface it can provide implementations for it's methods and most likely include state via instance fields.
Class-Only Pros:
elegant conceptual model doesn't force arbitrary modeling tradeoffs
can instantiate any non-abstract class Cons:
very difficult to come up with intuitive constructor semantics in diamond pattern
requires more overhead to implement in Java/CLR
Mixin Pros:
maps to JVM/CLR model much more cleanly
more efficient
easy to grok by Java/C# guys (or is this a con that we have been trained to think unnaturally)
constructor semantics are easier to define Cons:
inelegant - forces class designers to make a distinction
In either case the conflict rules would be as follows:
Static methods are inherited from all ancestors - name conflicts are ok (although calling static methods with the same name will require explicit type scope in subclasses)
Non-virtual instance methods with same name defined in two or more ancestors is illegal,and those types cannot be mixed together
A virtual method with exactly one implementation in an ancestor is inherited
A abstract virtual method with zero implementations in ancestors must be implemented in non-abstract classes (or optionally left deferred in abstract classes)
Virtual instance methods with different signatures defined in multiple ancestors is illegal
Virtual instance methods with the same signatures defined in multiple ancestors requires the class to override and provide an explicit definition
Right now I think I've pretty much made up my mind that the constructor issue is just too complicated. When you throw in the ability to model things more naturally in Java/C# using the mixin approach, I think that is the way to go.
brian Thu 29 Dec 2005
Recap our design discussions - some form of multiple inheritance is a must. Java/C# class vs interface is way too limiting to model real world problems. There are two practical approaches we have proposed:
In class-only inheritance there is only classes, and any class can extend one or more classes. In mixin inheritance we make a distinction between classes vs mixins. Basically a mixin is like an interface in that a class can extend only one other class, but mixin zero or more mixins. However unlike an interface it can provide implementations for it's methods and most likely include state via instance fields.
Class-Only Pros:
Mixin Pros:
In either case the conflict rules would be as follows:
Right now I think I've pretty much made up my mind that the constructor issue is just too complicated. When you throw in the ability to model things more naturally in Java/C# using the mixin approach, I think that is the way to go.