Multiple Inheritance of Classes

[superdan]

BCS Wrote:

> 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

hard time defending that post eh. he appealed to his own authority "this is the reason". then to an emotional word. then to majority.

see also http://en.wikipedia.org/wiki/Appeal_to_authority tho invoking wikipedia may also be a fallacy :)

> > 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.

i don't find either particularly reasonable. http://en.wikipedia.org/wiki/Appeal_to_ridicule
http://en.wikipedia.org/wiki/Argumentum_ad_populum. if you don't have the time to become an expert just let walter or some expert answer. that post reveals zero knowledge on the subject. merely a perpetuation of the "it's evil" heard from someone else and ingested noncritically. after "don't do it!!! it's evil!!!" all i can expect next is "keep the faith!!!" fuck man.

> > 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?"

"it's evil" is a good answer? cut the shit man. why is it evil again? your critical reasoning filter ever questioned that assertion?

> > 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.

pardon me if i'm dense but i have a hard time distinguishing between the two. and pardon me if i continue to think "it's evil" is mere oxshit.

> > 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's not debatable. interfaces are inheritance. they satisfy the definition. (substitution principle.) if you implement multiple interfaces you do mi. case closed. to summarize: d does mi of interface but not mi of data and not mi of implementation. they are different flavors of shit but that does not make interfaces mi debatable.

> > 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)

nothing that walt can't do.