Multiple Inheritance of Classes

[Yigal Chripun]

superdan wrote:
> Manfred_Nowak Wrote:
> 
>> superdan wrote:
>> 
>>> with mi it is impossible to lay out objects in a fixed layout. 
>>> unless you do it [...]
>> I do not understand this. Do you mean, that it is impossible or do
>> you mean one can do a fixed layout _with_ mi?
> 
> man there's a ton to explain and then some more. i got work n shit to
> do but let me try. stay with me ok? take a pen and paper and draw
> this shit. simple hierarchy:
> 
> class a { ubyte x[100]; } class b : a { ubyte y[200]; } class c : a {
> ubyte z[500]; }
> 
> let's lay a and b out. you could lay both out with the base first or
> last. you must be consistent. can't hand-pick your guesses. say you
> decide base first:
> 
> b : x y c : x z
> 
> so far so good. these decisions were made. can't be rethought later.
> because it's fixed layout, remember. put'em in ur pocket. now comes
> this motherfucker:
> 
> class bc : b, c {}
> 
> now you want b and c to be subobjects of bc with the same layout of b
> and c alone. so for bc there's only two cut and dried choices. either
> b then c or c then b. let's choose the first and unroll that shit:
> 
> bc : [ x y x z ]
> 
> but you don't want that because there are two xs where there should
> be one. see now how topological layout of a dag on a 1-dimensional
> line (linear memory) can't cut the shit.
> 
> but say you hand pick this example and make it work:
> 
> b : [ y z ] c : [ z x ] bc : [ y z x ]
> 
> youza that works. but then if you do this:
> 
> class d : b, bc {} class e : d, bc {}
> 
> that grandmotherfucks the entire situation. there's no way to lay
> that shit out. unless you know the hierarchy in advance. which is
> unreasonable. and you also have to allow for holes in objects. that
> also sucks ass.
> 
>> Then: given that "D is a systems programming language", how would
>> one implement an efficient system, for which a requirement for mi
>> exists, in D?
> 
> good question. i have two thoughts.
> 
> one is with stacked templates. that allows you not mi but stacked si.
> 
> 
> class a(t = Object) : t {} class b(t = Object) : t {} class ab :
> b!(a!()) {}
> 
> that way you draw your own layout on a line. it sucks that d doesn't
> allow a to mean a!(). the latter looks like shit. (i mean shit in a
> bad way.) but that's not true mi because different as and bs come
> templated with different arguments. they mean nothing to one another.
> that's only good for inheritance of implementation shit.
> 
> second thought. i think introspection may be the shit. (here i mean
> shit in a good way.) use classic layout for one base. then use
> indirection thru refs for the layout of the rest. introspection plops
> the forwarding functions. opImplicitCast adds seasoning for taste.
> this looks like some std.typecons shit.

About your first thought:
can you compare your (C++ templates) solution with D mixins?
why would I choose that approach instead of template mixins if it's only
good for inheritance of implementation?
I think (and I'm sure you'll correct me if I'm wrong) that mixins remove
the need for that pattern entirely.

In another post of yours you referred to adding function bodies to
interfaces. Do you have any ideas on how to implement this efficiently?

last question: can you explain what do you mean by non fixed layout
languages that have MI?