Multiple Inheritance of Classes

[lurker]

I hate to even think of it but on this one I am with Superdan. Don't get me wrong I think he is the worst scar this group has. I think he has a real problem with the way he treats people and I wouldn't want to be his coworker or neighbor. Most of his posts are so vile I feel like puking when I read them and I blocked him a long time ago. In this thread I saw his posts in quotes and I almost wish I didn't. But I have to say if he had minimal skills at writing he would of won this argument hands down. 

I for one was firmly in the "mi is evil" camp on unclear grounds of ambiguity. Lars feel-good post only inforced that. Now my understanding has changed. (Many thanks especially to Dee Girl.)

Most disappointing is one thing. When Lars answered to Superdan in a civilized manner he had an excellent opportunity at showing his class. But he missed it by neither affirming nor denying he knew about the layout problem. That leaves us facing the uncomfortable possibility that he didn't know about it but he did not have the strength to admit it.

Steven Schveighoffer Wrote:

> "superdan" wrote
> > 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. appeal to ridicule. appeal to the majority. all in 
> > one sentence. wow. at least could you space out your fallacies a bit more.
> >
> > 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.
> 
> This kind of bullying bullshit does nothing to further communication, or 
> help anyone in the least.  You've managed to call many of the brightest 
> developers for D idiots, usually based on useless crap like this (which has 
> no bearing on anything).  So shut the fuck up.
> 
> > below's an attempt at an answer.
> 
> Good answer.
> 
> > interfaces could implement functions. that does make a lot of sense. 
> > example:
> >
> > interface Customer
> > {
> >    string ssn();
> >    string name();
> >    string uniqueName() { return name ~ "(ssn: " ~ ssn ~ ")"; }
> > }
> >
> > 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?
> 
> What do you pass as the 'this' pointer?  When you call a function on an 
> interface, the compiler uses the offset of an interface to the 'this' 
> pointer to get to the object, but in this case, there is no object, so what 
> does the compiler do to call the ssn() and name() functions while 
> implementing this function?
> 
> If you pass the interface pointer as the 'this' pointer, then how do you 
> override it in an Object that implements the interface?  The function in the 
> concrete class can't be passed the interface pointer, so you can't really 
> override it.
> 
> One possible solution is to mark uniqueName as 'final', which means it 
> cannot be overridden.  Then you can safely pass the interface pointer to the 
> function (casting to the interface if necessary).  This might be a handy 
> thing when you always want to implement the same function in all concrete 
> classes in terms of the interface functions.
> 
> -Steve 
> 
>