Multiple Inheritance of Classes

[Robert Fraser]

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.

So why not just dissalow diamond-pattern MI?