www.digitalmars.com         C & C++   DMDScript  

D - Multiple inheritance is a must for people from C++ world

reply satelliittipupu <satelliittipupu_member pathlink.com> writes:
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!
Mar 18 2004
next sibling parent reply "Matthew" <matthew stlsoft.org> writes:
 It says in the comparison page that D doesn't have multiple inheritance.


It does not


 This is one of the most usefull and timesaving thing in the way I program


C++.

It depends what you use it for. Multiple inheritance of implementation is
evil, and has fallen very much out of favour with the C++ community over the
last decade. D does not, and will not, support that.

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.


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.


You should consider it anyway, as there are some really superb modules in
the standard library. ;)


 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!


Congratulations are mainly due Walter, but pretty much everyone on this NG
has helped in one way or another.

Hopefully you'll stick around!

Cheers

Matthew
Mar 18 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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?
What are bolt-in templates?

Just out of interest could you give an example?

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 18 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


 Matthew wrote:
=20

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


 What is tag inheritance?


    template< typename S
            , typename T =3D sequence_range_traits<S, =
is_const<S>::value>
            >
    class sequence_range
      : public iterable_range_tag // <=3D=3D ** this is the tag **
    {
    public:
      . . .

The tag identifies the range type, which is used in the range algorithms =
for selecting the most efficient algorithms.

The tags look like the following:

    struct simple_range_tag
    {};

    struct iterable_range_tag
      : public simple_range_tag
    {};

    struct noninterruptible_range_tag
    {};


[This is an extract from the STLSoft implementation of the Range =
concept, which I'm working on with John Torjo. Ranges will also likely =
feature large in DTL, although at the moment I've only got so far as =
doing the basic list, map, queue, set, stack and vector class =
implementations, and exchanging vague ponderings with big-W. As soon as =
he gets back from SDWest I expect to see a rapid movement


 What are bolt-in templates?


From [Wils04]:

=20

Definition: Bolt-ins

Bolt-ins are template classes with the following characteristics:

1. They derive, usually publicly, from their primary parameterising =
type.

2. They accommodate the polymorphic nature of their primary =
parameterising type. Usually they also adhere to the nature, but this is =
not always the case, and they may define virtual methods of their own, =
in addition to overriding those defined by the primary parameterising =
type.

3. They may increase the footprint of the primary parameterising type by =
the definition of member variables, virtual functions and additional =
inheritance from non-empty types.




=20
 Just out of interest could you give an example?


Classic examples are to be found in ATL, whereby several separate =
template classes may provide bolt-in behaviour, i.e. CComObject<>, =
CComObjectStack<>, etc.


A (really stupid) simple example (in C++):

class NumSequence
{
public:
  void PresentCalculation(ostream &os, int maxValue)
  {
    vector<int> things(this->CalcThings(maxValue));

    copy(things.begin(), things.end(), ostream_iterator<int>(os));
  }

protected:
  virtual vector<int> CalcThings(int maxValue) =3D 0;
};

template<typename S>
class FibonacciSequence
{
protected:=20
  virtual vector<int> CalcThings(int maxValue)
  {
    . . . calculate a Fibonacci sequence up to maxValue, and return in =
vector<int>
  }
};

template<typename S>
class PrimeSequence
{
protected:=20
  virtual vector<int> CalcThings(int maxValue)
  {
    . . . calculate a prime number sequence up to maxValue, and return =
in vector<int>
  }
};


int main()
{
  FibonacciSequence<NumSequence> ps().PresentCalculation(cout);
  PrimeSequence<NumSequence> ps().PresentCalculation(cout);
  return 0;
}

I'll leave it to all your great minds to figure out the amazing =
real-world benefits of this technique, rather than just my weak example.

In [Wils04], the sections in the Bolt-ins chapter are:

    22.1 Adding Functionality
    22.2 Skin Selection
    22.3 Non-virtual Overriding
    22.4 Leveraging Scope
    22.5 Simulated Compile-time Polymorphism
    22.6 Parameterised Polymorphic Packaging.

And if you want to know any more than that, you'll have to buy it =
(probably available around Sept/Oct). :)
Mar 18 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Mar 18 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
satelliittipupu wrote:


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!


  


Please provide an example where you need MI.
How many C++ programs do you know use MI?

D does provide a form of MI though the use of interfaces.

IMHO MI causes more problems then it solves.

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 18 2004
parent reply Zed <Zed_member pathlink.com> writes:
Heh. Please provide an example where MI causes problems.
:)
Mar 18 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Zed wrote:


Heh. Please provide an example where MI causes problems.
:)
  


I'll give a quote from: "concepts of programming languages" (5th ed), 
Robert W. Sebesta. p. 466-467.

"Because multiple inheritance is sometimes very useful, why would a 
language designer not include it?  The reasons fall into two categories: 
complexity and efficiency. The additional complexity is illustrated by 
several problems. One obvious problem is name collisions. For example, 
if a sub class named C inherits from both class A and class B and both B 
and both A and B include an inheritable variable named sum, how can C 
refer to the two different sums?" ... (the obvious answer is 
namespacing) ... "A variation of this occurs if both A and B are derived 
form a common parent, Z, in which case it is called diamond 
inheritance".  ...

"The question of efficiency may be more perceived then in real. In C++, 
for example supporting multiple inheritance requires just one extra 
additional operation for each dynamically bound method call (Stroustrup, 
1994, p. 270). Although this is required even if the program does not 
use multiple inheritance, it is a small additional cost".

At the risk of copying to much form this chapter "single and multiple 
inheritance", I'll summarise the rest.
- MI can lead to complex programs
- MI can hinders maintenance.
- Benefits not worth the effort.

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 18 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
J Anderson wrote:


 Zed wrote:


 Heh. Please provide an example where MI causes problems.
 :)


 I'll give a quote from: "concepts of programming languages" (5th ed), 
 Robert W. Sebesta. p. 466-467.

 "Because multiple inheritance is sometimes very useful, why would a 
 language designer not include it?  The reasons fall into two 
 categories: complexity and efficiency. The additional complexity is 
 illustrated by several problems. One obvious problem is name 
 collisions. For example, if a sub class named C inherits from both 
 class A and class B and both B and both A and B include an inheritable 
 variable named sum, how can C refer to the two different sums?" ... 
 (the obvious answer is namespacing but that has its own set of 
 problems) ... "A variation of this occurs if both A and B are derived 
 form a common parent, Z, in which case it is called diamond 
 inheritance".  ...

 "The question of efficiency may be more perceived then in real. In 
 C++, for example supporting multiple inheritance requires just one 
 extra additional operation for each dynamically bound method call 
 (Stroustrup, 1994, p. 270). Although this is required even if the 
 program does not use multiple inheritance, it is a small additional 
 cost".

 At the risk of copying to much form this chapter "single and multiple 
 inheritance", I'll summarise the rest.
 - MI can lead to complex programs
 - MI can hinders maintenance.
 - Benefits not worth the effort.


That should be:  Benefits may not worth the effort.

This is all very opinionative stuff, where there is no right answer, 
only good ones -> and the book hints at that.

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 18 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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.
Mar 18 2004
next sibling parent reply "Matthew" <matthew stlsoft.org> writes:
I believe that D should support more of MI than it currently does, but only
so far as tag classes and mixins.

The propagation of contructor arguments up diamond inheritance hierarchies
is a hideous wart, and should not be even attempted for D.

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:c3d1ri$1kmc$1 digitaldaemon.com...

 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.
Mar 18 2004
parent Juan C <Juan_member pathlink.com> writes:
Isn't "from" the operative word here? Anyone who likes Multiple Inheritance  can
stay with C++.
Mar 18 2004
prev sibling parent reply "Derek Parnell" <Derek.Parnell psyc.ward> writes:
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
Mar 18 2004
next sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
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
Mar 18 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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.
Mar 18 2004
parent ender <astrothayne gmail.com> writes:
I think that a restricted form of Multiple Inheritance (i.e. requiring author to
explicitly show which function to inherit in cases of ambiguity), all other
solutions use more code then is strictly necessary.
Jun 23 2007
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Mar 19 2004
next sibling parent reply "Matthew" <matthew stlsoft.org> writes:
"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.
Mar 19 2004
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
 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).
Mar 20 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
 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.
Mar 20 2004
next sibling parent reply larry cowan <larry_member pathlink.com> writes:
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.
Mar 20 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
larry cowan schrieb:


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


No, it currently isn't. And no to take a further question away, it isn't 
possible in C++ either, not even with export which is only supported in 
1/2 rarely used compilers.

I would imagine Walter has been thinking about providing such a faeture 
in a commercial compiler implemenatation, but now it's too early to 
care. D language puts no constraint to it.

-eye
Mar 20 2004
prev sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
 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.


My comment was about if the concept is really needed or not. Of course, if
something is useful, it needs some terminology, but you know what goes on:
some people like to produce as many buzzwords as possible. Hence the term
'buzzword-compliant', to show that one tries to impress with the use of as
many buzzwords as possible.


 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.


The example had an error in it, and this error made the example not easy to
be understood. (That is, If I have understood your example).


 Well, it must not be of any use then. Better tell all those ATL


programmers

ATL sucks.


 who have created literally hundreds of thousands (maybe millions) of


Hold on buddy. Millions ? :-)

COM sucks!!! (at least from good-old C++).


 perfectly useful


Well, give me an example one thing that I can do with ATL and can't do with
Java (for example).


 Oh, and a dash of realism about the
 extent of one's own knowledge is always useful as well, methinks.


That goes both ways.

Featuritis is a serious illness.
Mar 21 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c3k7ej$1gv2$1 digitaldaemon.com...

 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.


 My comment was about if the concept is really needed or not. Of course, if
 something is useful, it needs some terminology, but you know what goes on:
 some people like to produce as many buzzwords as possible. Hence the term
 'buzzword-compliant', to show that one tries to impress with the use of as
 many buzzwords as possible.


Hard to avoid in this game, though, isn't it. I don't know what to tell you.
There are a couple of useful things, and I applied names to them. You don't
like that because you don't believe the concepts are of any use and/or that
they shouldn't be given names.

I don't know what to tell you. It appears I can do nothing to ameliorate
your distress.


 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.


 The example had an error in it, and this error made the example not easy


to

 be understood. (That is, If I have understood your example).


It didn't have an error, at least AFAIK. It was inept and unconvincing. The
two things are quite different.


 Well, it must not be of any use then. Better tell all those ATL


 programmers

 ATL sucks.


Compared to what. Doesn't everything suck?

ATL is the best thing I know of for writing in-process COM servers, when one
is balancing robustness, flexibility and development time. What's better


 who have created literally hundreds of thousands (maybe millions) of


 Hold on buddy. Millions ? :-)


Hold on to what?

I said *maybe* millions. I don't know. There are reputed to be 5 million C++
programmers in the world. Let's say 50% of them program on Windows. I would
say all the COM programmers I know personally have written probably on
average 50-100 COM components each over the last 5-10 years. So to make it
into the millions, we only need 10-20,000 out of 2,500,000 Windows
programmers to be doing COM. That's 0.8% of them.

Let's say I'm wildly optimistic about how many COM components a C++ Windows
programmer might make, and let's say it's only 10. That still only requires
8% of them to have done COM.

Since COM has pervaded most aspects of Windows programming, do you think
it's that ridiculous to think that 8% of C++/Windows programmers have been
doing it?


 COM sucks!!! (at least from good-old C++).


I don't like to get personal, but that's such a dumb thing to say. COM is an
incredibly elegant concept, which has been screwed over by attempts to
shoehorn it into things it is not appropriate for, like DCOM and scripting.

Pure COM is wonderful, and widely appreciated ... has it not occured to you
to wonder that Walter has made D interfaces and COM interfaces binary
compatible? (I confess up front that Walter thinks pretty much the same
about COM as I do.)


 perfectly useful


 Well, give me an example one thing that I can do with ATL and can't do


with

 Java (for example).


LOL!

http://www.shellext.com/

Can you write those things in Java, and have them be as small (~50KB) and
requiring *nothing* but Win32 system libraries.

I'm sure you could find a million (well, hundred's of thousands, anyway) of
similar examples.


 Oh, and a dash of realism about the
 extent of one's own knowledge is always useful as well, methinks.


 That goes both ways.

 Featuritis is a serious illness.


Quite true, but the proof of the pudding is in the eating. If you still
think it's all a waste of time when the DTL's finished, I'll print the
entire source out, and eat it raw with a little Cianti.

:)
Mar 21 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Quite true, but the proof of the pudding is in the eating. If you still
think it's all a waste of time when the DTL's finished, I'll print the
entire source out, and eat it raw with a little Cianti.

:)
  


lol, what is Cianti?

Better make sure the code is short, I Achilleas may be to stubborn to 
change his mind :)
Mar 21 2004
next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
On Mon, 22 Mar 2004 01:46:21 +0800, J Anderson
<REMOVEanderson badmama.com.au> wrote:


Quite true, but the proof of the pudding is in the eating. If you still
think it's all a waste of time when the DTL's finished, I'll print the
entire source out, and eat it raw with a little Cianti.

:)
  


lol, what is Cianti?

Better make sure the code is short, I Achilleas may be to stubborn to 
change his mind :)


http://www.imdb.com/title/tt0102926/quotes

search for "chianti" (sp?)
Mar 21 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
Do you mean Fava beans and a nice Chianti?

J Anderson wrote:

 

 Quite true, but the proof of the pudding is in the eating. If you still
 think it's all a waste of time when the DTL's finished, I'll print the
 entire source out, and eat it raw with a little Cianti.

 :)
  


 
 lol, what is Cianti?
 
 Better make sure the code is short, I Achilleas may be to stubborn to 
 change his mind :)
Mar 21 2004
parent "Matthew" <matthew stlsoft.org> writes:
I do indeed. :)

"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:c3kl96$27o1$1 digitaldaemon.com...

 Do you mean Fava beans and a nice Chianti?

 J Anderson wrote:

 Quite true, but the proof of the pudding is in the eating. If you still
 think it's all a waste of time when the DTL's finished, I'll print the
 entire source out, and eat it raw with a little Cianti.

 :)


 lol, what is Cianti?

 Better make sure the code is short, I Achilleas may be to stubborn to
 change his mind :)
Mar 21 2004
prev sibling parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Ilya Minkov wrote:

 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.


Can someone point me in the direction of that?

I'm currently rolling an alternative Streams package, and I have to say, 
I keep thirsting for multiple inheritance. For I/O streams it makes a 
whole lot more sense, and offers a very elegant solution to splitting 
input and output. However, it's not going to happen. These mixins seem 
like they could desolve my frustration, though. But untill they're 
implemented, I'd love to see if one could work around the problem.

Cheers,
Sigbjørn Lund Olsen
Mar 21 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Sigbjørn Lund Olsen wrote:

 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.


 
 Can someone point me in the direction of that?


Certainly: <http://ikagames.com/andy/d/streams.d>

It's not perfect by a longshot, but it's a neat concept, and it works. :)

  -- andy
Mar 21 2004
parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Andy Friesen wrote:


 Sigbjørn Lund Olsen wrote:
 

 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.



 Can someone point me in the direction of that?


 
 
 Certainly: <http://ikagames.com/andy/d/streams.d>
 
 It's not perfect by a longshot, but it's a neat concept, and it works. :)
 
  -- andy


Hmm. On the off glance, maybe it's just me needing to look at it more 
closely, I don't see entirely how it would help me implement the 
Readable, Writable, and Seekable interfaces separately and then combine 
them in any sensible fashion. Must play a bit with it, I suppose.

Thanks, though.

Cheers,
Sigbjørn Lund Olsen
Mar 22 2004
prev sibling parent "Achilleas Margaritis" <axilmar b-online.gr> writes:
 I'm currently rolling an alternative Streams package, and I have to say,
 I keep thirsting for multiple inheritance. For I/O streams it makes a
 whole lot more sense, and offers a very elegant solution to splitting
 input and output. However, it's not going to happen. These mixins seem
 like they could desolve my frustration, though. But untill they're
 implemented, I'd love to see if one could work around the problem.


And why do you need to split an I/O class to input and output anyway? it is
silly. Just provide a IODevice superclass with an input AND output
interface, and have a File class which does I/O from files.

If the user tries to write from a read-only device, throw an exception. If
the user tries to read from a write-only device, throw an exception.

Inside those read/write operations you would check anyway for I/O errors, so
you could not say that you would save some code if multiple-inheritance was
allowed.

This is much simpler:

IODevice
  |--File
  |--Socket
  |--Pipe

than:
IODevice:
  |--IFile------|
  |--OFile-----|
                   |-IOFile

A single File class also reflects what a file really is: an input/output
device.

For me, it is quite frustrating to having to remember 'reader' classes and
'writer' classes and classes prefixed with 'i' and classes prefixed with
'o'. And I think it is silly. The only real benefit for such an API is to
make sure that someone that indends to read from a file would indeed read
from a file instead of writing to it...but if there was an error like this,
it would be the first to be caught anyway...

Keep it simple!
Mar 25 2004