Multiple Inheritance of Classes

Benji Smith dlanguage at benjismith.net
Tue Aug 12 15:12:29 PDT 2008


superdan wrote:
> better put doesn't do multiple inheritance of data. why? simple. d is a fixed layout language. means that the offset of any data member within the object is known during compilation. with mi it is impossible to lay out objects in a fixed layout. unless you do it the nonsensical way c++ does. at least you can't lay out with 1-dimensional memory. (i've done vlsi design and sure as shit 2-dim helps a lot. but a lot more could be done with 3-dim. i remember only adding two layers was a huge deal.) with mi from n classes you'd need n-dimensional ram. that's why only simple inheritance is possible with 1-dimensional ram. if u want fixed layout that is. (now that i got into it there was a guy who did 2-class inheritance by storing stuff at positive and negative offsets, thus adding a 2nd dimension.) mi of interfaces is a good thing and putting an int in an interface does not make it evil. just makes it impossible to lay out.

Which begs the question of why D is a fixed layout language. My 
impression is that, if MI was a high enough priority, the data layout 
issues could be easily solved (maybe by having the compiler 
automatically generate the necessary interfaces and mixins, and using a 
separate data layout for each inheritance permutation).

My understanding of *why* that route wasn't taken is that, from a design 
perspective, MI creates interface ambiguities that the programmer would 
usually rather not deal with. For example:

class A { public int xyz() { ... } }

class B { public int xyz() { ... } }

class C : A, B { ... }

C c = new C();
c.xyz(); // ambiguous

Sure, you could have the programmer explicitly disambiguate which xyz 
method to call, with something like this:

((A) c).xyz();

But is it really worth it, especially given the compiler gymnastics 
required to solve the data layout obstacles?

My impression has always been that the design consequences of MI in D 
made it undesirable (that's what people mean when they say that MI is 
"evil" or "ugly" or any of those other subjective, hyperbolic terms). 
The implementation hurdles could be overcome if MI was desirable, so 
it's not an insurmountable technical challenge as superdan's message 
implies.

I could be wrong in my recollection of the history of D, but that's how 
I remember the discussions from three or four years ago, when MI was a 
more commonly discussed topic. Mixins (code mixins, not string mixins, 
which didn't exist yet) were introduced specifically as a mechanism to 
avoid MI, avoiding code duplication without resorting to the ambiguities 
of MI.

--benji



More information about the Digitalmars-d mailing list