Isn't "from" the operative word here? Anyone who likes Multiple Inheritance  can stay with C++.

On Thu, 18 Mar 2004 13:46:42 -0700 (19/Mar/04 07:46:42 AM)
, Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote:

> Zed wrote:
>> Heh. Please provide an example where MI causes problems.
>> :)
>
> * Class constructors
> * Inheriting the same base class twice, throuth two children
>
> I tried once to learn the rules that goven "virtual" base classes, and was quickly convinced that MI had opened up a very difficult can of worms.
>
> Even if the complexity is managable through use of coding standards, the language (and thus the compiler) still has to support the most evil uses of MI.  It's better, IMHO, to just drop it altogether and end up with a simpler, more reliable compiler.
>

Okay, what you say makes sense, so let's stay with single inheritance then.

Given that, how would a coder use D in the situation where two classes exist, call them RoadVehicle and Boat, and the coder wishes to create a new class (AmphibiousVehicle) based on the already-coded-facilities in these two classes?

This is not a troll question but a real one. What are the tactics that a D coder could use to achieve this, with the minimum about of coding (especially duplicate coding)?

I can quickly see three approaches:

** Create the new class based on one of the existing classes and add code to emulate the omitted classes.

** Create the new class based on the common parent of both the existing classes, and add the code from both the omitted classes.

** Create the new class with no reference to any existing class.

-- 
Derek

Comments appended:

Derek Parnell wrote:
>...
> 
> Given that, how would a coder use D in the situation where two classes  exist, call them RoadVehicle and Boat, and the coder wishes to create a  new class (AmphibiousVehicle) based on the already-coded-facilities in  these two classes?
> 
> This is not a troll question but a real one. What are the tactics that a D  coder could use to achieve this, with the minimum about of coding  (especially duplicate coding)?
> 
> I can quickly see three approaches:
> 
> ** Create the new class based on one of the existing classes and add code  to emulate the omitted classes.
> 
> ** Create the new class based on the common parent of both the existing  classes, and add the code from both the omitted classes.
> 
> ** Create the new class with no reference to any existing class.
>

This is where the mixins proposal becomes useful.  (Big thanks to whoever it was that started that one rolling... I forget.)  You'd do something like:

<snip>
interface Vehicle { ... }
class StdVehicle : Vehicle { ... }
class RoadVehicle : StdVehicle { ... }
class Boat : StdVehicle { ... }
class AmphibiousVehicle : Vehicle, mixin RoadVehicle, mixin Boat { ... }
</snip>

Voila.  Also, for the record, we have MI in ColdC with no real problem, but then again its also bytecode compiled, and we don't have to worry about public layer inheritance, since in ColdC their virtually /is no/ public layer for anything other than methods.  The two don't compare at all, really, but I can't help thinking about the long drawn out rules for making MI work in ColdC, and don't think I'd want to learn a set of rules like that just to work with D objects.

-C. Sauls
-Invironz

Matthew wrote:

> > Matthew wrote:
> >
> > >However, modern template practices have revived the use for MI, in 
> so far as
> > >being able to apply tag inheritance to existing types via bolt-in 
> templates.
> > >D doesn't properly support this at the moment, though I have no 
> doubt that
> > >it will.
> > > 
> > >
> > What is tag inheritance?

Thanks, most interesting.

> And if you want to know any more than that, you'll have to buy it (probably available around Sept/Oct). :) 

Parhaps when I start getting a proper income :)

-- 
-Anderson: http://badmama.com.au/~anderson/

Assuming that the two classes preexist and we can't change them, I would do it like this:

class AmphibiousVehicle : RoadVehicle {
  Boat boatness;

  Boat GetBoat() { return boatness; }

  /* put a bunch of wrappers here that access stuff
   * in the 'boatness' object
   */
}

I know, it's ugly, and you don't get to do cast(Boat), but it's close.

Even better, if you are allowed to at least add to the existing class, would be to define an interface:

interface Boatness {
  /* all the stuff that boats have, as an interface */
}

class Boat : .....  , Boatness /*added this to existing class */ {
  /* class Boat is otherwise unmodified */
}

class AmphibiousVehcile : RoadVehicle, Boatness {
  /* same definition as I gave above */
}



The beauty of this is that you can now cast AmphibiousVehicle to something like a boat:
	Boatness foo = new Boat;
	Boatness bar = new AmphibiousVehicle;



If you're going to do this a lot, you could write a template to do it for you.  Forgive me, the template syntax may be a little off, but the idea is workable:

class AddBoatness(class X) : X, Boatness {
  Boat boatness;

  /* overload all those boat fields here */
}
alias AddBoatness!(RoadVehicle) AmphibiousVehicle;



Derek Parnell wrote:
> On Thu, 18 Mar 2004 13:46:42 -0700 (19/Mar/04 07:46:42 AM)
> , Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote:
> 
>> Zed wrote:
>>
>>> Heh. Please provide an example where MI causes problems.
>>> :)
>>
>>
>> * Class constructors
>> * Inheriting the same base class twice, throuth two children
>>
>> I tried once to learn the rules that goven "virtual" base classes, and  was quickly convinced that MI had opened up a very difficult can of  worms.
>>
>> Even if the complexity is managable through use of coding standards, the  language (and thus the compiler) still has to support the most evil uses  of MI.  It's better, IMHO, to just drop it altogether and end up with a  simpler, more reliable compiler.
>>
> 
> Okay, what you say makes sense, so let's stay with single inheritance then.
> 
> Given that, how would a coder use D in the situation where two classes  exist, call them RoadVehicle and Boat, and the coder wishes to create a  new class (AmphibiousVehicle) based on the already-coded-facilities in  these two classes?
> 
> This is not a troll question but a real one. What are the tactics that a D  coder could use to achieve this, with the minimum about of coding  (especially duplicate coding)?
> 
> I can quickly see three approaches:
> 
> ** Create the new class based on one of the existing classes and add code  to emulate the omitted classes.
> 
> ** Create the new class based on the common parent of both the existing  classes, and add the code from both the omitted classes.
> 
> ** Create the new class with no reference to any existing class.
> 

satelliittipupu schrieb:
> It says in the comparison page that D doesn't have multiple inheritance. This is
> one of the most usefull and timesaving thing in the way I program C++. All the
> other stuff about D sound very good, and if the multiple inheritance would be a
> reality in D, I might consider using it for my apps.
> Otherwise I have to congratulate you on your courage on making your own
> language. I like this kind of attitude, that when something isn't perfect and
> you can't change it, create the perfect thing on your own!

In D, Multiple inhritance would not work well, since all objects inherit from a common base, as opposed to C++ where they don't.

As a practical replacement for multiple inheritance, mix-ins and interfaces can hold. If i remember correctly, someone has shown how to implement mix-ins using templates in D.

-eye

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c3efej$1223$1@digitaldaemon.com...
> satelliittipupu schrieb:
> > It says in the comparison page that D doesn't have multiple inheritance.
This is
> > one of the most usefull and timesaving thing in the way I program C++.
All the
> > other stuff about D sound very good, and if the multiple inheritance
would be a
> > reality in D, I might consider using it for my apps.
> > Otherwise I have to congratulate you on your courage on making your own
> > language. I like this kind of attitude, that when something isn't
perfect and
> > you can't change it, create the perfect thing on your own!
>
> In D, Multiple inhritance would not work well, since all objects inherit from a common base, as opposed to C++ where they don't.

Good point. Tag inheritance would have to be allowable from structs.

> As a practical replacement for multiple inheritance, mix-ins and interfaces can hold. If i remember correctly, someone has shown how to implement mix-ins using templates in D.

They have, but despite the intellectual elegance of the solution, it's still a hack and not a good general solution. We need mixins.

> a hack and not a good general solution. We need mixins.

Does anybody care to give a good real-word example where multiple inheritance was needed and there was no alternative ? We can make up 'educational' examples like the Vehicle example above, but it real world, it is a rare case that something like multiple inheritance is needed.

Even in the vehicle example above, there could be lots of attributes than an amphibious vehicle would not have in common with boat/car/whatever.

KISS (keep it simple, stupid).

> Both techniques are useful but with a limited range of application.
Instead of
> providing so many buzzwords, people should strive for making things
simpler.
> Programming languages need not get more bloat.

Buzz words are bad, to be sure, but worse is not knowing what to call a concept and trying to pass on knowledge of it (via text postings) without any name for it. IMO, Tag Inheritance is an eminently meaningful term, for an extremely important concept. Please explain what's wrong with my using it in the responses I gave during this thread.

> In the bolt-in example you mentioned, I think the classes
FibbonacciSequence
> and PrimeSequence should inherit from NumSequence. I think that it is a
way
> overrated technique.

The example's not the best, of course, but then it was a made up on the spot, trying to be as simple as possible. I would be surprised if anyone didn't grok that pedagogical simplicity, but then clearly at least one has not. Next time, if I have time, I'll provide a more substantive example. (Of course, most readers of the NG probably don't have much time either, so maybe no-one would read such an example.)

> In a few words, bolt-ins means "selecting superclass from
> template parameter". Could it be useful in real world applications ? I
didn't need
> such a technique in my professional career as a programmer for the last 10
years.

Well, it must not be of any use then. Better tell all those ATL programmers who have created literally hundreds of thousands (maybe millions) of perfectly useful and mostly well implemented COM components over the last 8 years or so!

Sarcasm aside, one person's lack of need for a technique does not mean that technique is useless/irrelevant. For example, I have never used typeid in a commercial setting, not once, and I write a *lot* of C++ code. Does this mean that it should be dropped from the language, and the common knowledge base, on my say so. I hardly think so.

> What we need is a set or robust cross-platform libraries, instead of 'new programming paradigms' and little 'bolt-ins' or 'tag-inheritances'.

What we need is a set of good libraries, and a set of practitioners who are not profligate with introducing terminology for the sake of it but who are not afraid of it when it is necessary. Oh, and a dash of realism about the extent of one's own knowledge is always useful as well, methinks.

Are template files releaseable in any form which does not show the entire implementation?  I suppose you could make it depend on a library of type-specific routines, but...?

In article <c3hjaj$bnk$1@digitaldaemon.com>, Matthew says...
>
>
>> Both techniques are useful but with a limited range of application.
>Instead of
>> providing so many buzzwords, people should strive for making things
>simpler.
>> Programming languages need not get more bloat.
>
>Buzz words are bad, to be sure, but worse is not knowing what to call a concept and trying to pass on knowledge of it (via text postings) without any name for it. IMO, Tag Inheritance is an eminently meaningful term, for an extremely important concept. Please explain what's wrong with my using it in the responses I gave during this thread.
>
>> In the bolt-in example you mentioned, I think the classes
>FibbonacciSequence
>> and PrimeSequence should inherit from NumSequence. I think that it is a
>way
>> overrated technique.
>
>The example's not the best, of course, but then it was a made up on the spot, trying to be as simple as possible. I would be surprised if anyone didn't grok that pedagogical simplicity, but then clearly at least one has not. Next time, if I have time, I'll provide a more substantive example. (Of course, most readers of the NG probably don't have much time either, so maybe no-one would read such an example.)
>
>> In a few words, bolt-ins means "selecting superclass from
>> template parameter". Could it be useful in real world applications ? I
>didn't need
>> such a technique in my professional career as a programmer for the last 10
>years.
>
>Well, it must not be of any use then. Better tell all those ATL programmers who have created literally hundreds of thousands (maybe millions) of perfectly useful and mostly well implemented COM components over the last 8 years or so!
>
>Sarcasm aside, one person's lack of need for a technique does not mean that technique is useless/irrelevant. For example, I have never used typeid in a commercial setting, not once, and I write a *lot* of C++ code. Does this mean that it should be dropped from the language, and the common knowledge base, on my say so. I hardly think so.
>
>> What we need is a set or robust cross-platform libraries, instead of 'new programming paradigms' and little 'bolt-ins' or 'tag-inheritances'.
>
>What we need is a set of good libraries, and a set of practitioners who are not profligate with introducing terminology for the sake of it but who are not afraid of it when it is necessary. Oh, and a dash of realism about the extent of one's own knowledge is always useful as well, methinks.
>
>