Multiple Inheritance of Classes

[JAnderson]

Chris R. Miller wrote:
> Understand, I'm NOT demanding ANYTHING.
> 
> What is the current state of thought about Multiple Inheritance for 
> classes in D?  I'd like to have that feature, since it'd make some stuff 
> I want to do a bit easier.  Is it not there because it's not worth the 
> effort to implement?  Because it's evil and needs to die (I don't know, 
> some people could possibly be adamantly anti-MI)?  I don't know.  I know 
> I can add a lot with mixins, but I'd just like to know what the state of 
> the feature is.
> 
> The reason is I was trying to explain how cool D is to some other 
> friends of mine, and they asked about Multiple Inheritance (of classes) 
> and they were sort of put off by it's lack of it.  Then again, he was an 
> Objective-C programmer...  ;-)
> 
> So please don't take offense, since none is meant, I just wanted to know 
> what I could hope for in the future.
> 

I don't think MI is evil however I think there's only a few places where 
  it's actually a good design choice.  I think inheritance should mainly 
be used for polymorphism and not "reuse" (see : 101 Rules, Guidelines, 
and Best Practices (C++ In-Depth Series) -> by Herb Sutter and Andrei 
Alexandrescu).  By reuse of course I mean inheriting from a class that 
has partial implementation.

- Components provide better encapsulation because you have to go though 
the components interface to get at anything, which means you can provide 
a very strong invariant shield.
- Components can be many.  That is say you had a uni-cycle and you 
wanted to add more wheels.  You can with components.
- Components are not so tightly coupled.  You can (many times) remove 
the component without changing the interface.  You can also make changes 
to the components interface and have a very small ripple effect across 
the project.
- Components can provide there own interface and can be bound at 
runtime.  This means you can switch out the component as needed.
- Components can be passed around without dragging the entire class 
along for the ride.
- Not in the design area but... some companies working on consoles use 
components to get around v-table issues.

(Note I've only mentioned a few of the advantages of components.)

Anyway given that most of the time IMHO you shouldn't be using 
inheritance for implementation details / data.  Add to that mixins and 
bolt-in templates and it becomes even less likely that multiple 
inheritance with implementation is the best design for your application. 
  I think D has taken the right approach, which is to make it hard to 
write error-prone code.

-Joel