Multiple Inheritance of Classes

[BCS]

Reply to superdan,

> Lars Ivar Igesund Wrote:
> 
>> 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)?
>>> 
>> This is actually the reason, not the adamantly anti-MI part, just
>> that MI is evil and that is well acknowledged almost everywhere. You
>> will find good argumentation against it if you look, too.
>> 
> appeal to authority.

Always a good idea if, like most people, you don't plan on /becoming/ an 
authority

> appeal to ridicule. appeal to the majority.

Both reasonable if enough people are doing the ridicule (95% majority?), 
again with the disclaimer for the occasional expert/academic that most of 
us (walter excluded) don't have anywhere near the time to become.

> the man has kindly asked a sensible question. he deserves a good
> answer. if u can't give one just don't reply. this is just ignorance.
> 

I think that was a good answer to the question "Why doesn't D have MI?"

> below's an attempt at an answer.

The below is a reasonable answer to "Justify D's lack of MI." or "What is 
the rational for D's not having MI?" Those are different questions that what 
Lars was going for.

> 
> first i repeat what is already known. d does do multiple inheritance
> thru interfaces.

Is interfaces MI? That is debatable because, as you point out, there is a 
huge difference between it and MI->data & MI->implementation.

> it doesn't do multiple inheritance of implementation.
> better put doesn't do multiple inheritance of data.

[...]
> putting an int in an interface does not
> make it evil. just makes it impossible to lay out.
> 

In this context "evil" is a relative term. Nothing in programing it truly 
evil... Well maybe C++.
http://www-users.cs.york.ac.uk/~susan/joke/cpp.htm

> interfaces could implement functions. that does make a lot of sense.
> example:
> 
> interface Customer
> {
> string ssn();
> string name();
> string uniqueName() { return name ~ "(ssn: " ~ ssn ~ ")"; }
> }

Yeah, I've wanted that, OTOH it might get tricky to implement because of 
the mechanics of interfaces.

option 1: uniqueName becomes a implicit mixin that gets expanded per class 

code bloat, etc. but that's what we do manually anyway.

option 2: uniqueName has a single implementation that is shared by all implementing 
classes

This is an ugly solution because the only way to make that work would be 
to have this inside uniqueName be an interface reference, however as things 
stand interface references are turned into object references (by offsetting 
the pointer) on interface calls. Work around for this include doing this 
inside the functions and having an interface version and a non interface 
version of each function (not viable for closed source) or using little shells 
everywhere (errr, yuck, but it would work)

> so uniqueName formats a specific way. a descendant can choose to
> change that or just use the default. no idea why walt chose to
> disallow that. walt?
>