www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Multiple Inhertiance?

reply "Patrick Jeeves" <pdj9 pitt.edu> writes:
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.
Nov 05 2014
next sibling parent Justin Whear <justin economicmodeling.com> writes:
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.
Nov 05 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 05 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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?
Nov 06 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 06 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Nov 06 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 06 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Nov 06 2014
prev sibling parent reply "Patrick Jeeves" <pdj9 pitt.edu> writes:
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.
Nov 06 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Nov 06 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 6 November 2014 at 15:25:11 UTC, Patrick Jeeves
wrote:

 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.


Multiple inheritance have various issue, like the well known
diamond shaped inheritance problem. There are also many
implementation issues when it come to object layout and base
class retrial, which are all trivial with a single inheritance
model.

Considering it come with problems, both in term of language
design and efficient implementation, it has to pull its weight.
And I'm yet to see a good use case for it.

In the other hand, alias this (or prototypal inheritance model in
general) do not suffer from these issues. It also have some good
use case like entity framework.
Nov 06 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 6 November 2014 at 21:56:39 UTC, deadalnix wrote:

 In the other hand, alias this (or prototypal inheritance model 
 in
 general) do not suffer from these issues. It also have some good
 use case like entity framework.


I'm curious as to how prototypical inheritance avoids the diamond 
inheritance problem. Is it due to the fact that it doesn't 
require a virtual call, and thus, ambiguous cases can be caught 
at compile time?
Nov 06 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 6 November 2014 at 22:15:25 UTC, Meta wrote:

 On Thursday, 6 November 2014 at 21:56:39 UTC, deadalnix wrote:

 In the other hand, alias this (or prototypal inheritance model 
 in
 general) do not suffer from these issues. It also have some 
 good
 use case like entity framework.


 I'm curious as to how prototypical inheritance avoids the 
 diamond inheritance problem. Is it due to the fact that it 
 doesn't require a virtual call, and thus, ambiguous cases can 
 be caught at compile time?


Because the base "object" and delegated "object" are different
one, not the same being polymorphic.
Nov 06 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 7 November 2014 at 03:28:45 UTC, deadalnix wrote:

 Because the base "object" and delegated "object" are different
 one, not the same being polymorphic.


That does not resolve conflicts with having the same base 
prototype or name conflicts in method names. Ignoring the issues 
does not make them go away…
Nov 06 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 7 November 2014 at 07:12:58 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 7 November 2014 at 03:28:45 UTC, deadalnix wrote:

 Because the base "object" and delegated "object" are different
 one, not the same being polymorphic.


 That does not resolve conflicts with having the same base 
 prototype or name conflicts in method names. Ignoring the 
 issues does not make them go away…


Conflict will cause error and you can specify which road you want 
to take explicitly. This has nothing to do with alias this, but 
with identifier resolution in general. imported symobl for 
instance, suffer from the same issue.
Nov 06 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 7 November 2014 at 07:41:26 UTC, deadalnix wrote:

 want to take explicitly. This has nothing to do with alias 
 this, but with identifier resolution in general. imported 
 symobl for instance, suffer from the same issue.


The diamond problem involves the desire to only have a single 
instance of the shared base class. Not a resolution issue.

That said, I don't like unqualified imports much. They tend to 
make code less readable when you scale up.
Nov 10 2014