So what's bothering me is that I can do this:

class NullType {}
class Monkey(T) : T {}
class Zombie(T) : Monkey!T {}
class Robot(T)  : Monkey!T {}
class Pirate(T) : Monkey!T {}
class Ninja(T)  : Monkey!T {}

class MultipleInheritance : Zombie!(Robot!(Pirate!(Ninja!NullType))) {};

To get mutliple inheritance.  I just don't understand what the purpose of not allowing multiple inheritance is if I can get around it this easily, and its far less managable than it would be if it had language support.

On Thu, 06 Nov 2014 00:39:11 +0000, Patrick Jeeves wrote:

> So what's bothering me is that I can do this:
> 
> class NullType {}
> class Monkey(T) : T {}
> class Zombie(T) : Monkey!T {}
> class Robot(T)  : Monkey!T {}
> class Pirate(T) : Monkey!T {}
> class Ninja(T)  : Monkey!T {}
> 
> class MultipleInheritance : Zombie!(Robot!(Pirate!(Ninja!NullType))) {};
> 
> To get mutliple inheritance.  I just don't understand what the purpose of not allowing multiple inheritance is if I can get around it this easily, and its far less managable than it would be if it had language support.

Short answer: that's not multiple inheritance.  That hierarchy has a
simple,
well-defined order of method lookup and overriding, so things like the
diamond
problem are not possible.

Patrick Jeeves:

> To get mutliple inheritance.  I just don't understand what the purpose of not allowing multiple inheritance is if I can get around it this easily, and its far less managable than it would be if it had language support.

I think not giving language support means that D designers don't want it to be easy to do. And this is good.

Bye,
bearophile

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?

Ola Fosheim Grøstad:

> Then why are they adding multiple alias this, which appears to be worse?

The multiple alias this is being designed right now. If you don't like the complexities it introduces, then it's a good moment to express your concerns in that thread (I plan to not use multiple alias this much).

Bye,
bearophile

On Thursday, 6 November 2014 at 08:38:53 UTC, bearophile wrote:
> Ola Fosheim Grøstad:
>
>> Then why are they adding multiple alias this, which appears to be worse?
>
> The multiple alias this is being designed right now. If you don't like the complexities it introduces, then it's a good moment to express your concerns in that thread (I plan to not use multiple alias this much).

I have, quite strongly, pointed out that alias this is a static version of prototype based programming (like javascript). And that self (which is based on prototype based programming) had multiple inheritance but removed it because:

1. it was not used much
2. it lead to confusion about which method was called

I also pointed out that D should not keep adding features that makes it more badly typed.

I think D should either try to support programming in the large or stop claiming that D aims to stop programming in the large while not being willing to make the feature set suitable.

Ola Fosheim Grøstad:

> I think D should either try to support programming in the large or stop claiming that D aims to stop programming in the large while not being willing to make the feature set suitable.

Think of C++17/D2 as testbed entities that contain most features, to test what works and what doesn't work, to create successive languages that contain only the useful features :-)

(I still don't have desire for multiple alias this at this moment. I'd like tuple unpacking, more value range analysis, something to enforce preconditions at compile-time, a built-in yield/yieldAll, and little else).

Bye,
bearophile

On Thursday, 6 November 2014 at 09:03:02 UTC, bearophile wrote:
> Think of C++17/D2 as testbed entities that contain most features, to test what works and what doesn't work, to create successive languages that contain only the useful features :-)

:-) Yes, I view D2 as an experiment. And I view your and other's contributions in the forums as very useful for getting more nuances when it comes to various features for a statically compiled language.

Anyway when doing language design one should strive to:

1. Understand how it works in other languages that have generalized the concept.

2. Figure out if you are actually providing N different ways of expressing the same concept.

(3. Stop claiming innovation without doing proper research of the field.)

The problem with this view of adding many features is that they work against each other if they are not designed in tandem (as a whole). This is seen quite clearly in C++.

> (I still don't have desire for multiple alias this at this moment. I'd like tuple unpacking, more value range analysis, something to enforce preconditions at compile-time, a built-in yield/yieldAll, and little else).

Yep, language support for tuples would be valuable. It is not easy to add this late though, if you want them to be powerful and play nice with rest of the language.

I think D would benefit from focusing on compile time resolution. In that context alias this might make some sense, especially if you ripped out the class concept.

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.

On Thursday, 6 November 2014 at 15:25:11 UTC, Patrick Jeeves wrote:
> I don't really see how multiple alias this is better or worse
> than multiple inheritance.

It is worse because:

1. When you design a class hierarchy with multiple inheritance you don't reuse something made for another purpose, you design it as a whole for a particular purpose and you can use virtual base class and virtual function to resolve problems.

2. "multiple alias this" messes with the type system in bad ways. Classical multiple inheritance does not (due to the resolution mechanisms).

But there is no good reason to include either because you should model not from the object, but from how you care going to use the object. Therefore you can usually decide one view as more important for a particular application.

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

If you want good MI then you need to build the language around it from the start, but you can always do without.

Yes, that means you have to select one perspective and break down the model in a different way, but it isn't that hard to do. And you can resolve conflicts by adding virtual functions in the base class if you want that kind of model.

For a game it would be better to break up the representation for the game object into more than a single aggregate. Using MI and a single object is going to hurt performance.