Multiple Inheritance of Classes

[Dee Girl]

Chris R. Miller Wrote:

> superdan wrote:
> > Chris R. Miller 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.
> >> Looking at superdan's message, gee whiz, that didn't take long to find 
> >> the implementational reasons against it.
> > 
> > the sinner tells the truth dood. it's not the implementation reasons. it's the reasons, period. there's no others. with one exception (smalltalk) all languages without fixed field layout do use mi. why? because aside from field layout there is no reason not to, and they already paid the price. this "it's evil" bullshit comes from c++ people tryin' it in wrong ways. just like java 1 zealots yelled all over that generics are crap. then java 5 added (assfucked) generics. guess what. javaots changed their stance. sorry about the argument by comparison fallacy :)
> 
> That's humorous coming from you, seeing as how you tauted nothing but 
> implementation reasons.
> 
> I know a lot of Java "zealots," and they were never anti-template.  The 
> zealots in your neck of the woods must be more bipolar than mine.
> 
> >> Reading about next-gen compilers like LLVM it makes me wonder with all 
> >> that run-time type inferencing gizmo gadgetry available at virtually no 
> >> cost, will this make MI (for those who want it) more feasible to 
> >> implement?  Hmm, a curious possibility to consider.  LLVM is supposed to 
> >> be wicked fast, too.  My Apple friend tells me that most of OS X's GL 
> >> stack is built with LLVM for speed.  There might be something to it.
> > 
> > i'll make another analogy. with all that research n shit, isn't perpetual motion closer to reality now? hell no. the fact that llvm is fast or smart has nothing to do with basic graph topology. the problem definition makes a solution impossible. this will be broken when someone invents some associative memory shit or some fundamental breakthrough. or when the cost of malloc and indirection becomes small enough to be affordable (solution through tradeoff inversion).
> 
> Perpetual motion is slightly different than a new and experimental 
> approach to a compiler.
> 
> >>>> 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...  ;-)
> >>> In the languages where MI is possible, it usually also is possible to not
> >>> shoot your own foot with some care, in which case it can appear as a
> >>> powerful feature. But almost everywhere it just is a very bad idea, and you
> >>> will find it is banned in many projects for languages allowing it (like
> >>> C++).
> >> Look long enough and you can find anything.  ;-)
> >>
> >> I see your point though.
> > 
> > i don't. he has none. he keeps on saying it's a "very bad idea". he could sing it for all i care. how does that make it more pointful.
> 
> You continue to amuse me.  First I say I see his point.  You say you 
> don't.  You say he has no point.  Therefore you're absolutely certain 
> that even though someone else sees his concept that it is either false 
> or not there, or both.
> 
> >>>> So please don't take offense, since none is meant, I just wanted to know
> >>>> what I could hope for in the future.
> >>> You should hope you can redesign your application to not need MI ;)
> >> Yeah, it's trivial to work around it (I did come from Java!) but some 
> >> bits and pieces seem like it would be better if they could inherit 
> >> behavior and data, not just a contract.  It could be done through a 
> >> mixin, but that defeats the polymorphism I want present in the design. 
> >> And a Mixin and an interface just seems clunky.  What if I do the mixin 
> >> but forget the interface, or vice-versa?  Yuk!  Though it would give me 
> >> the option of re-implementing it differently if necessary...  a curious 
> >> silver lining.
> > 
> > the silver lining is in introspection. with it you can define classes that define forwarding functions to other classes. that is almost mi, good enough for many uses.
> 
> I don't see how that would restore polymorphism.  Short code example, 
> perhaps?

I do not know exact how he meant. But I tell how I think it can be. This is how I implement in my project (simplified because I have negative offset).

class Base1
{
    int i1;
    void f1() {}
}

class Base2
{
    int i2; 
    void f2() {}
}

Goal to define Derived that inherits Base1 and Base2. Derived override both f1 and f2. And contains both i1 and i2. Also Derived implicit convert to Base1 and Base2. Very hard! But can be done. Strategy is derive from one and contain other.

class Derived : Base1
{
    override void f1() {}
    private Base2 b2;
    void f2() { return b2.f2; }
}

This is first try. I do not put constructor to simplify code. Assume b2 initialized ok. Converts to Base1 but not Base2. Let us fix:

class Derived : Base1
{
    override void f1() {}
    private Base2 b2;
    void f2() {}
    Base2 opImplicitCast() { return b2; }
}

Now converts to both. Like inheritance! But see last problem. And most complex. f2 does not override f2 in base. I did it manual but here I use inner classes because they make code simple.

class Derived : Base1
{
    override void f1() {}
    class Base2Hook : Base2
    {
        override void f2() { return outer.f2; }
    }
    private Base2Hook b2;
    void f2() {}
    Base2 opImplicitCast() { return b2; }
}

Now we have all. Derived implements both f1 and f2 and contains i1 and i2. Converts implicit to Base1 and Base2. When you call f2 on the Base2 part correct function is called. It is all good! But it is one more indirection for the Base2 part. Also there is code boring (boilerplate). With introspection it can be generated. So ideal solution is:

class Derived : Base1
{
    override void f1() {}
    mixin(innerHookForwarder("Base2Hook", "Base2"));
    private Base2Hook b2;
    Base2 opImplicitCast() { return b2; }
    void f2() {}
}

Maybe simpler:

class Derived : Base1
{
    mixin(psuedoInheritance("Base2", "b2"));
    override void f1() {}
    void f2() {}
}

Now I want to make comment that I hope does not offend some body. I agree that "Multiple Inheritance Is Evil" is very incorrect. Even as joke this answer only...what word... promotes (I think) ignorance and propagates rumors. People agree and laugh and teach other people same mistake. I am sorry if my words are not expressive. I hope the meaning is understood. It is disappointing to see people still use and like this answer but do not want to know the sense. Some part of programming is science and some is social. But we should not mix when possible. Also I hope no offense but it is nice when people talk peaceful. Not fight and bad words. We can have information and good discussion same time. Why one but not an other? It is hard for my poor English to understand message ^_^ Again I hope no offense for any body. If you do not like it please ignore. Thank you, Dee Girl