"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c72t3c$17ug$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c70o8q$v8e$1@digitaldaemon.com...
> >
> > "Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c702on$bb$1@digitaldaemon.com...
> > >
> > > "fred" <info@fleet-manage.com> wrote in message news:c6v5uf$1mne$1@digitaldaemon.com...
> > > > My feelings exactly !
> > > >
> > > > Although both concepts address a similar problem i.e. the use of
> Multiple
> > > > Inheritance
> > > > (MI) in legacy code. Both idea are coming at it from different
> directions,
> > > > DTL needs
> > > > a mechanism for providing a standard implementation to multiple
> classes,
> > > > whereas
> > > > Aggregation is aimed at proving language support to a key OO concept.
> > > >
> > > > I still believe there is a lot of merit for including aggregation
> > > inherently
> > > > as part of the D programming language, since IMHO it is the biggest
> > > > shortcoming
> > > > of C++, and one of the main reasons for the overuse (or misuse) of MI.
> > > >
> > > > So I will rehash my Mixin Specification, renaming it as Aggregation
> and
> > > let
> > > > it
> > > > rise and fall on its own merits.
> > > >
> > > > regards fred
> > > >
> > > >
> > > >
> > > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c6uu3n$1bpr$1@digitaldaemon.com...
> > > > > I think the mixin idea and aggregation idea should be separated at
> this
> > > > point.
> > > > >
> > > > > Although I find most arguments for language-assisted aggregation
> pretty
> > > > > unconvincing, that may well be just because of the way I program, or
> the
> > > > type of
> > > > > programs I write, or whatever.
> > > > >
> > > > > There seems to have been broad agreement for my mixins idea in terms
> of
> > > > how it
> > > > > meets the requirements I have. Those requirements are primarily for
> DTL
> > > at
> > > > this
> > > > > point, but I see it as fundamental to have a widely applicable
> > > > enumeration/range
> > > > > mixin mechanism that may be applied to *anything* that has opApply.
> > > > (Naturally,
> > > > > I'm thinking of the Search class of std.recl, but it applies equally
> > > well
> > > > to
> > > > > other classes.) This would be allow the D equivalent to STLSoft, if
> you
> > > > like, to
> > > > > be achievable with a simple ", mixes Ranges" statement in the
> intialiser
> > > > list of
> > > > > any class which has opApply().
> > > > >
> > > > > As far as aggregation goes, this seems to me to be an entirely
> different
> > > > matter,
> > > > > and I respectfully suggest that it be separated out with its own
> syntax
> > > > and
> > > > > keywords. It may well be a widely needed and desired feature, and
> should
> > > > stand
> > > > > (or fall) on its own.
> > > > >
> > > > > Just my t'uppence, anyhow.
> > > > >
> > > > > Matthew
> > >
> > > I don't think mixins are needed for an STL-like library. 'Search' can be
> a
> > > function, as in C++, and then each collection can have a method which
> calls
> > > this function.
> >
> > Now that's a useful suggestion.
> >
> > > I also think that multiple inheritance is also not needed. For example,
> why
> > > does a stream class has to be derived from input stream and output
> stream ?
> > > just have one stream class with input and output capabilities, and throw
> an
> > > exception if the stream is not readable or not writable. It's simple, it
> is
> > > elegant, why mess with it ?
> >
> > The mixing of input and output is one of my least favourite features of
> any
> > class. I think I've seen precisely one example where I+O was needed in one
> class
> > in 15 years of programming. I've never written any stream classes where
> they were
> > joined, and no-one's ever complained.
> >
> > The idea of having something that can be either, and finding out at
> runtime
> > whether it is or not is, to put it crudely, crap. Compile-time is always
> better
> > than runtime.
> >
> >
>
> Why is it crap ? from one side, we have the trouble of putting multiple inheritance in D; from the other side, we have the 'crap' of stream classes which can do input and output. Which one is heavier to do and will create the most problems ? I think the first one: putting multiple inheritance/aggregation/mixins/whatever in D.

And reaching Mars and inventing the perfect ice-cream are challenging tasks.

What have the two things to do with each other? I'm not advocating MI, and I'm not advocating I + O streams. So what's your point?

> I really see no problem with streams doing input and output together. It will take a few minutes (perhaps less than a minute) for a programmer to find out if there is a problem; since an exception is to be thrown on an operation that is not allowed, there is no logical problem either.

What if the "programmer" doesn't find out until the product's been deployed. It could be an extremely expensive few minutes.

> It also simplifies the class diagram and the number of classes the programmer needs to remember.

Wrong. It complicates the class diagram but reduces the number of classes the programmer needs to remember.

If this is your argument, why do we have any classes at all? Why not one uber-class, with all the methods anyone could ever want for anything?

Have you seen MFC? Think it's an example of good orthogonal design?

> I agree that compile-time is better than run-time, but the cost and effort of putting multiple inheritance in a programming language like D certainly outweights any benefits of the compile-time approach at this particular case.

That sentence does not make sense. Yes, CT is better than RT, and I'm *not* arguing for MI.

> Nobody may need to read and write to the same stream simultaneously, I agree with this. But it is not a matter of usage, it is a matter of simplifying the object model, reduce the number of classes, and most importantly, have D easily implementable in other environments (GNU D, for example).

It complicates the object model. Can anyone out there seriously tell me that they think the C++ iostreams represent a simple class model?

Why does "fewer classes" equate with "simple model"? I rather think it's the other way round.

Why does a more complex class represent something more easily ported? In all my experience of writing portable code, the reverse is true. Can you offer tangible examples to support your hypothesis?

> Another approach is for the base stream class to implement both input and output, and derived classes to hide one of input/output facilities. Instead of 'stream' inheriting from 'istream' and 'ostream', the 'istream' and 'ostream' classes inherit from 'stream' but hide the output and input capabilities, respectively.

And this would be simpler than just having them separate in the first place?!

Come on

In article <c73sha$2o7n$1@digitaldaemon.com>, Matthew says...
>
>
>"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c72t3c$17ug$1@digitaldaemon.com...
>>
>> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c70o8q$v8e$1@digitaldaemon.com...
>> >
>> > "Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c702on$bb$1@digitaldaemon.com...
>> > >
>> > > "fred" <info@fleet-manage.com> wrote in message news:c6v5uf$1mne$1@digitaldaemon.com...
>> > > > My feelings exactly !
>> > > >
>> > > > Although both concepts address a similar problem i.e. the use of
>> Multiple
>> > > > Inheritance
>> > > > (MI) in legacy code. Both idea are coming at it from different
>> directions,
>> > > > DTL needs
>> > > > a mechanism for providing a standard implementation to multiple
>> classes,
>> > > > whereas
>> > > > Aggregation is aimed at proving language support to a key OO concept.
>> > > >
>> > > > I still believe there is a lot of merit for including aggregation
>> > > inherently
>> > > > as part of the D programming language, since IMHO it is the biggest
>> > > > shortcoming
>> > > > of C++, and one of the main reasons for the overuse (or misuse) of MI.
>> > > >
>> > > > So I will rehash my Mixin Specification, renaming it as Aggregation
>> and
>> > > let
>> > > > it
>> > > > rise and fall on its own merits.
>> > > >
>> > > > regards fred
>> > > >
>> > > >
>> > > >
>> > > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c6uu3n$1bpr$1@digitaldaemon.com...
>> > > > > I think the mixin idea and aggregation idea should be separated at
>> this
>> > > > point.
>> > > > >
>> > > > > Although I find most arguments for language-assisted aggregation
>> pretty
>> > > > > unconvincing, that may well be just because of the way I program, or
>> the
>> > > > type of
>> > > > > programs I write, or whatever.
>> > > > >
>> > > > > There seems to have been broad agreement for my mixins idea in terms
>> of
>> > > > how it
>> > > > > meets the requirements I have. Those requirements are primarily for
>> DTL
>> > > at
>> > > > this
>> > > > > point, but I see it as fundamental to have a widely applicable
>> > > > enumeration/range
>> > > > > mixin mechanism that may be applied to *anything* that has opApply.
>> > > > (Naturally,
>> > > > > I'm thinking of the Search class of std.recl, but it applies equally
>> > > well
>> > > > to
>> > > > > other classes.) This would be allow the D equivalent to STLSoft, if
>> you
>> > > > like, to
>> > > > > be achievable with a simple ", mixes Ranges" statement in the
>> intialiser
>> > > > list of
>> > > > > any class which has opApply().
>> > > > >
>> > > > > As far as aggregation goes, this seems to me to be an entirely
>> different
>> > > > matter,
>> > > > > and I respectfully suggest that it be separated out with its own
>> syntax
>> > > > and
>> > > > > keywords. It may well be a widely needed and desired feature, and
>> should
>> > > > stand
>> > > > > (or fall) on its own.
>> > > > >
>> > > > > Just my t'uppence, anyhow.
>> > > > >
>> > > > > Matthew
>> > >
>> > > I don't think mixins are needed for an STL-like library. 'Search' can be
>> a
>> > > function, as in C++, and then each collection can have a method which
>> calls
>> > > this function.
>> >
>> > Now that's a useful suggestion.
>> >
>> > > I also think that multiple inheritance is also not needed. For example,
>> why
>> > > does a stream class has to be derived from input stream and output
>> stream ?
>> > > just have one stream class with input and output capabilities, and throw
>> an
>> > > exception if the stream is not readable or not writable. It's simple, it
>> is
>> > > elegant, why mess with it ?
>> >
>> > The mixing of input and output is one of my least favourite features of
>> any
>> > class. I think I've seen precisely one example where I+O was needed in one
>> class
>> > in 15 years of programming. I've never written any stream classes where
>> they were
>> > joined, and no-one's ever complained.
>> >
>> > The idea of having something that can be either, and finding out at
>> runtime
>> > whether it is or not is, to put it crudely, crap. Compile-time is always
>> better
>> > than runtime.
>> >
>> >
>>
>> Why is it crap ? from one side, we have the trouble of putting multiple inheritance in D; from the other side, we have the 'crap' of stream classes which can do input and output. Which one is heavier to do and will create the most problems ? I think the first one: putting multiple inheritance/aggregation/mixins/whatever in D.
>
>And reaching Mars and inventing the perfect ice-cream are challenging tasks.

No comment here.

>
>What have the two things to do with each other? I'm not advocating MI, and I'm not advocating I + O streams. So what's your point?

Multiple inheritance and I/O ? but the most classic example of MI is the stream example: there is istream, ostream and stream which inherits from both.

>
>> I really see no problem with streams doing input and output together. It will take a few minutes (perhaps less than a minute) for a programmer to find out if there is a problem; since an exception is to be thrown on an operation that is not allowed, there is no logical problem either.
>
>What if the "programmer" doesn't find out until the product's been deployed. It could be an extremely expensive few minutes.

Do you mean that deployment will take place without running the application once ?

>
>> It also simplifies the class diagram and the number of classes the programmer needs to remember.
>
>Wrong. It complicates the class diagram but reduces the number of classes the programmer needs to remember.

Why does it complicate it ? If there are fewer classes, it means a simpler class diagram.

>
>If this is your argument, why do we have any classes at all? Why not one uber-class, with all the methods anyone could ever want for anything?

You are going from one extreme end to the other now. My argument applies to streams and I/O architecture, not everything.

>
>Have you seen MFC? Think it's an example of good orthogonal design?

MFC is the silliest piece of code ever written. It's sole purpose is to make C++ look difficult and turn developers to Visual Basic, which is Microsoft's proprietary language. The only product which uses MFC is Visual Studio. All other Microsoft products use internal code.

>
>> I agree that compile-time is better than run-time, but the cost and effort of putting multiple inheritance in a programming language like D certainly outweights any benefits of the compile-time approach at this particular case.
>
>That sentence does not make sense. Yes, CT is better than RT, and I'm *not* arguing for MI.

But mixins is a form of multiple inheritance.

>
>> Nobody may need to read and write to the same stream simultaneously, I agree with this. But it is not a matter of usage, it is a matter of simplifying the object model, reduce the number of classes, and most importantly, have D easily implementable in other environments (GNU D, for example).
>
>It complicates the object model. Can anyone out there seriously tell me that they think the C++ iostreams represent a simple class model?
>
>Why does "fewer classes" equate with "simple model"? I rather think it's the other way round.

Because the programmer knows that he/she can use one class for everything related to stream I/O. He/she does not have to remember other names. It's simpler. The different Input and Output stream classes propagates to other types of streams too, not only file I/O, making the class model huge. For example, in Java, there is:

BufferedInputStream
BufferedOutputStream
BufferedReader
BufferedWriter
ByteArrayInputStream
ByteArrayOutputStream
CharArrayReader
CharArrayWriter
DataInputStream
DataOutputStream
File
FileDescriptor
FileInputStream
FileOutputStream
FilePermission
FileReader
FileWriter
FilterInputStream
FilterOutputStream
FilterReader
FilterWriter
InputStream
InputStreamReader
LineNumberInputStream
LineNumberReader
ObjectInputStream
ObjectOutputStream
ObjectStreamClass
ObjectStreamField
OutputStream
OutputStreamWriter
PipedInputStream
PipedOutputStream
PipedReader
PipedWriter
PrintStream
PrintWriter
PushbackInputStream
PushbackReader
RandomAccessFile
Reader
SequenceInputStream
StreamTokenizer
StringBufferInputStream
StringReader
StringWriter
Writer

It is an impressive list of classes, and it is good for adertisement, but unnecessary in my opinion, especially because a lot of classes simply offer different I/O data types.

>
>Why does a more complex class represent something more easily ported? In all my experience of writing portable code, the reverse is true. Can you offer tangible examples to support your hypothesis?

You did not understand. I did not say that a more complex class makes something more easily ported. I said that the compiler is more easily ported, if it does not support MI.

>
>> Another approach is for the base stream class to implement both input and output, and derived classes to hide one of input/output facilities. Instead of 'stream' inheriting from 'istream' and 'ostream', the 'istream' and 'ostream' classes inherit from 'stream' but hide the output and input capabilities, respectively.
>
>And this would be simpler than just having them separate in the first place?!

It would be simpler because it would not require any language modifications.

>
>Come on
>
>
>

Hey, there is no need to be unfriendly. I am just expressing my opinions, that might be wrong. That's why we have debates.

Anyway.

Maybe the best way to introduce mixins in the language is to provide a new language construct analogous to struct/class/interface. Structs have the role of memory mapping; interfaces have the role of expressing certain 'agreement' between parts; classes are the constructs where data and implementation are bound together.

A new element 'mixin' could be introduced that binds together data and code, but it has the following constraints:

a) it can't be instantiated; it has to be inherited.
b) common fields between mixins are unified.
c) it can have methods, but its methods are not overridable.
d) mixins can inherit one or more mixins.
e) mixins don't inherit from Object.
f) mixins don't have implicit behaviour, as in constructors and destructors.
g) mixins are accessed from classes using their names.

Here is an example:

//mixins

public mixin ifstream {
public int handle;
public void open();
}

public mixin ofstream {
public int handle;
public void open();
}

public mixin fstream : ifstream, ofstream {
}


//classes

public class IFStream : ifstream {
}


public class OFStream : ofstream {
}

public class FStream : fstream {
}


In the above example, mixin 'ifstream' and mixin 'ofstream' are unified in the mixin 'fstream', and the 'handle' field is common in the 'fstream' composition.

The above mechanism is in effect a form of 'multiple inheritance', without actually being 'multiple inheritance' as we know it from C++. It may simplify many design issues, since it allows sharing of implementations and data between classes without the headaches of actual C++-style multiple inheritance.

Mixins (and similarly MI) add flexibility. With flexibility comes
complexity:
 http://www.artima.com/intv/flexplex2.html
The question (obviously) is whether the increased flexibility is worth the
complexity both to the language and to user code. C++ is very flexible but
it is also very complex. I'm up in the air about whether mixins are worth
it. Are there any "gotcha"s that will surprise people like there are with
MI?

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c75ek4$1vtk$1@digitaldaemon.com...
> Mixins (and similarly MI) add flexibility. With flexibility comes
> complexity:
>  http://www.artima.com/intv/flexplex2.html
> The question (obviously) is whether the increased flexibility is worth the
> complexity both to the language and to user code. C++ is very flexible but
> it is also very complex. I'm up in the air about whether mixins are worth
> it. Are there any "gotcha"s that will surprise people like there are with
> MI?
>
>

As I proposed in my reply to Matthew (look above), there is a solution to avoid the complexity of C++ multiple inheritance and have the benefits of multiple inheritance at the same time. Here is my proposal:

A new element 'mixin' could be introduced that binds together data and code,
but
it has the following constraints:

a) it can't be instantiated; it has to be inherited.
b) common fields between mixins are unified.
c) it can have methods, but its methods are not overridable.
d) mixins can inherit one or more mixins.
e) mixins don't inherit from Object.
f) mixins don't have implicit behaviour, as in constructors and destructors.
g) mixins are accessed from classes using their names.

In other words, mixins can be arbitrary compositions of data and code without object-orientation rules.

On 2004-05-01 19:54:44 +0200, "Matthew" <matthew.hat@stlsoft.dot.org> said:

> 
> 
> The idea of having something that can be either, and finding out at runtime
> whether it is or not is, to put it crudely, crap. Compile-time is always better
> than runtime.

This is a bit off-topic, but these sort of generalizations get my goat up. CT is better than RT. If you go through your programming life with that attitude, you're asking for trouble.

CT has one advantage over RT --- performance --- and that is only important for certain types of software.

In nearly every other way, RT is preferable. I can write code in python or objective C that is much more compact, readable, and robust than anything I write in C, C++ or Fortran. Why? Because the flexibility of dynamic typing makes implementing unit tests extremely easy, much easier than in C++, for example. So in a dynamic language, you are more inclined to perform run-time tests, and not rely solely on the compiler (which 99% of C++ programmers do, in my view). That a program comes through the compiler is absolutely no guarantee that it is correct.

One thing I like about D is that it can offer the performance of compile-time, whilst often seeming almost like a dynamic language. When I program with D, it seems almost as easy and flexible as python, which is a big plus for the language.

Anyway, these sorts of arguments tend to end up being religious discussions, so I'll leave it here. I would like to leave off though with a reference to a nice weblog by a well-known C++ proponent, Bruce Eckel, on this very topic:

http://www.mindview.net/WebLog/log-0025

Drew McCormack

> > The idea of having something that can be either, and finding out at runtime whether it is or not is, to put it crudely, crap. Compile-time is always
better
> > than runtime.
>
> This is a bit off-topic, but these sort of generalizations get my goat up. CT is better than RT. If you go through your programming life with that attitude, you're asking for trouble.

If you say so. I'd be interested to see any examples where a reasoned preference for compile-time has caused an issue.

>
> CT has one advantage over RT --- performance --- and that is only important for certain types of software.

Quite untrue. In fact, when I referred to it I had not even considered performance, though in many instances the advantageous effect you refer to is seen.

The *real* reason that compile-time errors are preferred is that the developer finds out the errors at the time the program is being built, rather than at an arbitrary and unspecifiable epoch in the future.

Please let me know what the flaws to this are. I'd be

> In nearly every other way, RT is preferable. I can write code in python or objective C that is much more compact, readable, and robust than anything I write in C, C++ or Fortran. Why? Because the flexibility of dynamic typing makes implementing unit tests extremely easy, much easier than in C++, for example. So in a dynamic language, you are more inclined to perform run-time tests, and not rely solely on the compiler (which 99% of C++ programmers do, in my view). That a program comes through the compiler is absolutely no guarantee that it is correct.

Since I don't ascribe to that viewpoint - of relying on the compiler to do my dynamic testing for me - your point it moot.

Anyone that thinks that the compiler can solve all their problems is a fool, or a newbie, or both. That viewpoint is as flawed as the notion that errors should be left for later when they can be appropriately dealt with earlier.

> One thing I like about D is that it can offer the performance of compile-time, whilst often seeming almost like a dynamic language. When I program with D, it seems almost as easy and flexible as python, which is a big plus for the language.
>
> Anyway, these sorts of arguments tend to end up being religious discussions, so I'll leave it here. I would like to leave off though with a reference to a nice weblog by a well-known C++ proponent, Bruce Eckel, on this very topic:
>
> http://www.mindview.net/WebLog/log-0025

I fail to see the relevance of this to this thread, but all power to your elbow for bringing in some big guns.

"Drew McCormack" <drewmccormack@mac.com> wrote in message news:c7a70n$5n9$1@digitaldaemon.com...
> Anyway, these sorts of arguments tend to end up being religious discussions, so I'll leave it here. I would like to leave off though with a reference to a nice weblog by a well-known C++ proponent, Bruce Eckel, on this very topic:
>
> http://www.mindview.net/WebLog/log-0025

One of the great things about Bruce Eckel is his willingness to fundamentally change his opinions when faced with contrary evidence, unlike most people who will construct elaborate rationalizations in order to avoid having to confront being wrong.

Let's assume for a moment that Bruce is correct in that runtime type checking is just as robust, and enables faster program development. Why, then, is D a statically typed language? It is for performance reasons. When the compiler knows exactly what type something is, it can customize the code for that type.

>Let's assume for a moment that Bruce is correct in that runtime type checking is just as robust, and enables faster program development. Why, then, is D a statically typed language? It is for performance reasons. When the compiler knows exactly what type something is, it can customize the code for that type.

bingo - choose the right tool for the problem at hand, I can't understand why people can't see the need for both types of languages or they try to force Walter to go "dynamic", there are plenty of dynamic languages to choose from now

"Mark T" <Mark_member@pathlink.com> wrote in message news:c7bfq3$25nd$1@digitaldaemon.com...
> >Let's assume for a moment that Bruce is correct in that runtime type checking is just as robust, and enables faster program development. Why, then, is D a statically typed language? It is for performance reasons.
When
> >the compiler knows exactly what type something is, it can customize the
code
> >for that type.
>
> bingo - choose the right tool for the problem at hand, I can't understand
why
> people can't see the need for both types of languages or they try to force Walter to go "dynamic", there are plenty of dynamic languages to choose
from now
>
>

Or D could have a 'variant' type which accounts for any type and it is used exactly like a dynamic type (D does not need to be solely dynamic or static; it could be static, or dynamic when using the 'variant' type).

It will also solve the problem of safe variable argument lists.

Now that is a *nice* idea. Instead of us all fighting over which particular variant library is best it'll just be in the language. It'd be nice if it

Maybe the last pre-1.0 feature (along with mixins, of course)?!


"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c7bldu$2efl$1@digitaldaemon.com...
>
> "Mark T" <Mark_member@pathlink.com> wrote in message news:c7bfq3$25nd$1@digitaldaemon.com...
> > >Let's assume for a moment that Bruce is correct in that runtime type checking is just as robust, and enables faster program development. Why, then, is D a statically typed language? It is for performance reasons.
> When
> > >the compiler knows exactly what type something is, it can customize the
> code
> > >for that type.
> >
> > bingo - choose the right tool for the problem at hand, I can't understand
> why
> > people can't see the need for both types of languages or they try to force Walter to go "dynamic", there are plenty of dynamic languages to choose
> from now
> >
> >
>
> Or D could have a 'variant' type which accounts for any type and it is used exactly like a dynamic type (D does not need to be solely dynamic or static; it could be static, or dynamic when using the 'variant' type).
>
> It will also solve the problem of safe variable argument lists.
>
>
>