Re: Multiple Inhertiance?
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.
Re: Multiple Inhertiance?
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?
Re: Multiple Inhertiance?
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
Re: Multiple Inhertiance?
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.
Re: Multiple Inhertiance?
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
Re: Multiple Inhertiance?
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.
Re: Multiple Inhertiance?
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.
Re: Multiple Inhertiance?
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.
Re: Multiple Inhertiance?
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.
Re: Multiple Inhertiance?
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?
Re: Multiple Inhertiance?
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.
Re: Multiple Inhertiance?
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…
Re: Multiple Inhertiance?
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.
Multiple Inhertiance?
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.
Re: Multiple Inhertiance?
On Thu, 06 Nov 2014 00:39:11 +, 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.
Re: Multiple Inhertiance?
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
