Suggestion: Walter Bright, why not to implement multiple inheritance in D?

[Kyle Furlong]

Gregor Richards wrote:
> Arlen Albert Keshabyan wrote:
>> Recently, I've started the subject about multiple inheritance in D. 
>> I've got
>> the answers. But those solutions are not enough suitable for my 
>> purposes. Then
>> I thought, why not to implement the feature which is on demand by 
>> programmers
>> in D? Multiple inheritance is needed indeed just only by seeing the 
>> attempts
>> of programmers to emulate it in D. It means they need it. Multiple 
>> inheritance
>> is really not that bad thing which is supposed to be got rid of. Just 
>> a linear
>> multiple inheritance with possibility to get to the every level of its
>> hierarchy is enough, I think. Moreover, I'll help to port many useful 
>> C++ code
>> into D much easier than now.
>>
>> I know two approaches by now, but both are restrictive to feel the 
>> freedom of
>> multiple inheritance.
>>
>> First approach is excellent, but does not allow you to get as deep as 
>> you want
>> to the class hierarchy (only super's virtual methods are accessible 
>> explicitly):
>>
>> Walter, is it a matter of principle not to implement multiple 
>> inheritance in
>> D?
> 
> No.
> 
>> If D is the language of practical usage then multiple inheritance must be
>> considered to implement.
> 
> Yeah, obviously. I mean, who the hell uses Java or C#?
> 
>> What do you think?
> 
> Multiple inheritance is a terrible idea on at least two levels:
> 
> 1) In class trees with functions or (worse yet) variables with the same 
> name at different levels, it's confusing to the programmer to figure out 
> what name maps to what.
> 
> 2) The way OO is implemented in 99% of compiled programming languages, 
> multiple inheritance is impossible. Let me explain:
> 
> // this is the structure representing an object
> struct Object {
>     struct ClassInfo *classInfo;
>     struct RandomGarbage whateverTheLanguageNeeds;
>     // variables go here
> }
> 
> // this is the structure representing a class
> struct ClassInfo {
>     struct ClassInfo *parent;
>     // <many other things>
>     void **vtable;
> }
> 
> 
> vtable is an array of function pointers, like so for example
> class A.vtable =
> 0 -> foo()
> 1 -> foo(int)
> 
> now imagine we have a class derived from the one described above. To 
> make it usable as the base class, it has a vtable like this
> class A(B).vtable =
> 0 -> foo()
> 1 -> foo(int)
> 2 -> bar()
> 3 -> bar(float)
> 
> Hey presto! If you pass in an object with this vtable, it will work for 
> both, because calling the function foo just involves calling vtable[0]!
> 
> 
> Now, imagine the multiple-inheritance scenario. We have these two classes:
> class A.vtable =
> 0 -> foo()
> 1 -> foo(int)
> 
> class B.vtable =
> 0 -> baf()
> 1 -> baf(Object)
> 
> Now we'd like to make a class C derived from both A and B:
> class C(A, B).vtable =
> 0 -> ???
> 1 -> ???
> 2 -> (C's own functions)
> 
> Now can you see the problem? We can't simply dereference vtable[0] or 
> vtable[1] to get the proper function, because there are two different 
> classes, each with their own vtable[0] and vtable[1].
> 
> There are solutions to this (obviously, since C++ works), but they're 
> usually arcane and always inefficient.
> 
>  - Gregor Richards

The Gregor (tm) strikes again!