Multiple Inheritance of Classes

[Dee Girl]

Benji Smith Wrote:

> 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).

I think this is very correct. But without "easy" word in there ^_^. Without entire hierarchy knowledge you can not make good layout. And I think that limits very much the power of language.

I know language Dylan. It has sealed domains. They mean an entire hierarchy that is known. One author of Dylan gave a talk at the Uni that I saw. He explained how sealed domains allow good layout. Also faster function dispatch because all possible functions are known. But I agree. Multiple inheritance is not important so much to justify the cost. So languages work without it. But it is not evil! ^_^

> 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 am sorry. But I think this understanding is mistaken. The ambiguity problem is also with interfaces. They require implementing all functions. Then it is OK to ask to override all ambiguous functions in a MI scheme. It is not worse then interfaces. To call you can use classic member access A.xyz or B.xyz.

Superdan is correct. The problem with state is insurmountable. I did not know what it means and I look it up now ^_^. It is. I implemented it and it is not about what function to call or ambiguous. It is always data data data. Where can you put data to make every body happy. Multiple inheritance effects very much the entire store model. You lose "prefix property" and then everything is much complicated!

> 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.

I am sure Walter knows perfectly. It is about data. I am sorry but I disagree ambiguity is major problem or problem at all. Sorry, Dee Girl