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

Chris Nicholson-Sauls ibisbasenji at gmail.com
Fri Dec 1 14:17:57 PST 2006


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):
> 
> //////////////////////////////////
> interface I
> {
> }
> 
> class A(T) : T, I
> {
> }
> 
> class B(T) : T, I
> {
> }
> 
> class C(T) : T, I
> {
> }
> 
> alias C!(B!(A(Object))) D;
> ////////////////////////////////
> 
> Second approach is excellent too, but lacks template merging possibilities and
> pointing explicitly which interface function to implement (on name collisions):
> 
> //////////////////////////////////////
> interface A
> {
> }
> 
> interface B
> {
> }
> 
> interface C
> {
> }
> 
> template A_()
> {
> }
> 
> template B_()
> {
> }
> 
> template C_()
> {
> }
> 
> class D : A, B, C
> {
>    mixin A_;
>    mixin B_;
>    mixin C_;
> }
> ////////////////////////////////
> 
> Walter, is it a matter of principle not to implement multiple inheritance in
> D? If D is the language of practical usage then multiple inheritance must be
> considered to implement.
> What do you think?

I'm not Walter, and I'm no expert in the implementation of languages, and I am in fact 
guilty of using multiple inheritance often enough...  But I will say this much.  I've been 
working on implementing my own BovisMOO language for a project, and within Bovis I've 
allowed for multiple inheritance, despite its predecessor (LambdaMOO) being strictly 
single inheritance.  Which caused a very simple lookup which looked roughly (pseudo-code) 
like this:

#  while (obj && !(pname in obj.fieldDefinitions)) { obj = obj.parent; }
#  if (obj is null) {
#    // no such property error, throw an exception
#  }
#  // do work with the property

To now look like this:

#  if (!(pname in obj.fieldDefinitions)) {
#    foreach (o; &obj.traverseAncestryBreadthFirstEnsuredOnce) {
#      if (pname in o.fieldDefinitions) {
#        obj = o;
#        break;
#      }
#      if (o is Database.instance.rootObject) {
#        // no such property error, throw an exception
#      }
#    }
#  }
#  // so do work with the property

All off the top of my head, but that's more-or-less how it goes.  Yes, it does work, but 
it sure became a lot uglier and a lot less efficient... and this is just for a weak-typed 
little scripting language with no concepts of classes or interfaces!  I can only imagine 
what horrors it might lead to in a full systems programming language with rich OOP 
features.  I'd say the main reason it isn't there, is to prevent Walter from having 
migraines.  And I don't consider that a completely unmerited excuse.  :)

-- Chris Nicholson-Sauls



More information about the Digitalmars-d mailing list