Multiple Inhertiance?

[Patrick Jeeves via Digitalmars-d]

On Thursday, 6 November 2014 at 08:04:33 UTC, Ola Fosheim Grøstad
wrote:
> On Thursday, 6 November 2014 at 00:50:23 UTC, bearophile wrote:
>> I think not giving language support means that D designers 
>> don't want it to be easy to do. And this is good.
>
> Then why are they adding multiple alias this, which appears to 
> be worse?

I don't really see how multiple alias this is better or worse
than multiple inheritance.  They descirbe completely different
relationships, Multiple Aliasing describes an is-both
relationship, while Multiple Inheritance describes an
is-from-a-certian-point-of-view-a relationship.  Atttempting to
use compositing to emulate will only result in feature envy, data
duplication, the space of the bookkeeping needed to share the
data exceeding the space of the data being shared, cache misses,
etc.

e.g.

Say I have a GameObject with the following policies:
CollisionPolicy, SpritePolicy, PhysicsPolicy, AudioPolicy,
ScriptPolicy.  They all need to use the data of
position/size/velocity/rotation to do their respective jobs.  The
collision data is going to be in the sprite file so the
CollisionPolicy has to talk to the SpritePolicy, the
PhysicsPolicy is going to need to get data from the
CollisionPolicy, but there may not be one if impulses get
imparted to it directly, etc.

It makes sense to say it HAS all of these policies, but the
feature envy shows that that isn't true, unlike how a car has an
engine, it IS each of these from a certian point of view: and not
a composition of them from any point of view.  This also
frequently causes the diamond inheritance problem in my
experience: some piece of data is needed by all of the component
parts, but intrinsic to none of them, so theres no way to decide
who should own it.

e.g.

position is needed by all the parts of GameObject, but never used
by the GameObject itself--infact GameObject may be defined
entirely as the intersection of the subjective perceptions of
it's component parts. So who does the field belong to? All those
parts could potentially exist without the any one of the others.
The sensible solution would be to have all of them have a
position feild that gets composited into a single field, but
theres no syntax to declare that intention in any language; so:
diamond inheritance happens.  Nor is there a way to change a
class based on the others included, e.g. CollisionPolicy will
change depending on if there is a SpritePolicy at all, only some
combinations of policies are valid, but I think this has to do
with the halting problem and is impossible to deal with.

IMHO MI is too useful a feature to be left out of any language,
even if most languages butcher it to the point that it's used as
an is-both relationship.