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

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

 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

 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 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:
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

 Matthew wrote:
=20
However, modern template practices have revived the use for MI, in so =


being able to apply tag inheritance to existing types via bolt-in =


D doesn't properly support this at the moment, though I have no doubt =


it will.
 =20


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 


being able to apply tag inheritance to existing types via bolt-in 


D doesn't properly support this at the moment, though I have no 


it will.
 



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!


  

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

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.

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.


 one of the most usefull and timesaving thing in the way I program C++.


 other stuff about D sound very good, and if the multiple inheritance


 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


 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.

 providing so many buzzwords, people should strive for making things

 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

 and PrimeSequence should inherit from NumSequence. I think that it is a

 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

 such a technique in my professional career as a programmer for the last 10

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.

 providing so many buzzwords, people should strive for making things

 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

 and PrimeSequence should inherit from NumSequence. I think that it is a

 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

 such a technique in my professional career as a programmer for the last 10

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

 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

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)


 any name for it. IMO, Tag Inheritance is an eminently meaningful term,


 an extremely important concept. Please explain what's wrong with my


 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

 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

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

 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