www.digitalmars.com         C & C++   DMDScript  

D - Mixins and aggregation - it was nice while it lasted, but it's time to part ...

reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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
Apr 30 2004
next sibling parent reply "fred" <info fleet-manage.com> writes:
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

 Although I find most arguments for language-assisted aggregation pretty
 unconvincing, that may well be just because of the way I program, or the

 programs I write, or whatever.

 There seems to have been broad agreement for my mixins idea in terms of

 meets the requirements I have. Those requirements are primarily for DTL at

 point, but I see it as fundamental to have a widely applicable

 mixin mechanism that may be applied to *anything* that has opApply.

 I'm thinking of the Search class of std.recl, but it applies equally well

 other classes.) This would be allow the D equivalent to STLSoft, if you

 be achievable with a simple ", mixes Ranges" statement in the intialiser

 any class which has opApply().

 As far as aggregation goes, this seems to me to be an entirely different

 and I respectfully suggest that it be separated out with its own syntax

 keywords. It may well be a widely needed and desired feature, and should

 (or fall) on its own.

 Just my t'uppence, anyhow.

 Matthew

Apr 30 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 My feelings exactly !

 Although both concepts address a similar problem i.e. the use of Multiple
 Inheritance
 (MI) in legacy code.

Actually, I disagree with this, although only in the fine details. I don't seek MI, but rather an inside-out bolt-in. (But that's me going off and using my own terminology again. Future readers of "Imperfect C++" will get what I mean <G>.) A bolt-in (in C++) is a template that derives from its primary parameterising type. It can be used to adjust type & behaviour of extant classes.
 Both idea are coming at it from different directions,
 DTL needs
 a mechanism for providing a standard implementation to multiple classes,

Actually, mixins have two uses. The minor one (from a strategic POV) is being able to "reuse" functionality across type-distinct, but logically related (i.e containers, or container-like classes). The major one is having a mechanism to turn *any* freachable type into a fully-fledged Range citizen, merely by the exercise of the "mixes" keyword. I believe this will come to be one of the most powerful mechanisms in D, at least as far as collections are concerned. (btw, I'm working on some C++ stuff that might be similar, but it's too early, even for myself, to even postulate this as likely.)
 whereas
 Aggregation is aimed at proving language support to a key OO concept.

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

Yes, the more I think about it, the more I think it will be a positive addition.
 So I will rehash my Mixin Specification, renaming it as Aggregation and let
 it
 rise and fall on its own merits.

Please do. I look forward to seeing the details.
 "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

 Although I find most arguments for language-assisted aggregation pretty
 unconvincing, that may well be just because of the way I program, or the

 programs I write, or whatever.

 There seems to have been broad agreement for my mixins idea in terms of

 meets the requirements I have. Those requirements are primarily for DTL at

 point, but I see it as fundamental to have a widely applicable

 mixin mechanism that may be applied to *anything* that has opApply.

 I'm thinking of the Search class of std.recl, but it applies equally well

 other classes.) This would be allow the D equivalent to STLSoft, if you

 be achievable with a simple ", mixes Ranges" statement in the intialiser

 any class which has opApply().

 As far as aggregation goes, this seems to me to be an entirely different

 and I respectfully suggest that it be separated out with its own syntax

 keywords. It may well be a widely needed and desired feature, and should

 (or fall) on its own.

 Just my t'uppence, anyhow.

 Matthew


Apr 30 2004
prev sibling parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
"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

 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

 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

 Although I find most arguments for language-assisted aggregation pretty
 unconvincing, that may well be just because of the way I program, or the

 programs I write, or whatever.

 There seems to have been broad agreement for my mixins idea in terms of

 meets the requirements I have. Those requirements are primarily for DTL


 this
 point, but I see it as fundamental to have a widely applicable

 mixin mechanism that may be applied to *anything* that has opApply.

 I'm thinking of the Search class of std.recl, but it applies equally


 to
 other classes.) This would be allow the D equivalent to STLSoft, if you

 be achievable with a simple ", mixes Ranges" statement in the intialiser

 any class which has opApply().

 As far as aggregation goes, this seems to me to be an entirely different

 and I respectfully suggest that it be separated out with its own syntax

 keywords. It may well be a widely needed and desired feature, and should

 (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. 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 ? If you have a good example of multiple inheritance that can't be done without it in an elegant way, I would be more than happy to read about it.
May 01 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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

 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

 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

 Although I find most arguments for language-assisted aggregation pretty
 unconvincing, that may well be just because of the way I program, or the

 programs I write, or whatever.

 There seems to have been broad agreement for my mixins idea in terms of

 meets the requirements I have. Those requirements are primarily for DTL


 this
 point, but I see it as fundamental to have a widely applicable

 mixin mechanism that may be applied to *anything* that has opApply.

 I'm thinking of the Search class of std.recl, but it applies equally


 to
 other classes.) This would be allow the D equivalent to STLSoft, if you

 be achievable with a simple ", mixes Ranges" statement in the intialiser

 any class which has opApply().

 As far as aggregation goes, this seems to me to be an entirely different

 and I respectfully suggest that it be separated out with its own syntax

 keywords. It may well be a widely needed and desired feature, and should

 (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.
May 01 2004
next sibling parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
"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



 Inheritance
 (MI) in legacy code. Both idea are coming at it from different



 DTL needs
 a mechanism for providing a standard implementation to multiple



 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

 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



 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




 point.
 Although I find most arguments for language-assisted aggregation




 unconvincing, that may well be just because of the way I program, or




 type of
 programs I write, or whatever.

 There seems to have been broad agreement for my mixins idea in terms




 how it
 meets the requirements I have. Those requirements are primarily for




 at
 this
 point, but I see it as fundamental to have a widely applicable

 mixin mechanism that may be applied to *anything* that has opApply.

 I'm thinking of the Search class of std.recl, but it applies equally


 to
 other classes.) This would be allow the D equivalent to STLSoft, if




 like, to
 be achievable with a simple ", mixes Ranges" statement in the




 list of
 any class which has opApply().

 As far as aggregation goes, this seems to me to be an entirely




 matter,
 and I respectfully suggest that it be separated out with its own




 and
 keywords. It may well be a widely needed and desired feature, and




 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


 function, as in C++, and then each collection can have a method which


 this function.

Now that's a useful suggestion.
 I also think that multiple inheritance is also not needed. For example,


 does a stream class has to be derived from input stream and output


 just have one stream class with input and output capabilities, and throw


 exception if the stream is not readable or not writable. It's simple, it


 elegant, why mess with it ?

The mixing of input and output is one of my least favourite features of

 class. I think I've seen precisely one example where I+O was needed in one

 in 15 years of programming. I've never written any stream classes where

 joined, and no-one's ever complained.

 The idea of having something that can be either, and finding out at

 whether it is or not is, to put it crudely, crap. Compile-time is always

 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. 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. It also simplifies the class diagram and the number of classes the programmer needs to remember. 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. 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). 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.
May 02 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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



 Inheritance
 (MI) in legacy code. Both idea are coming at it from different



 DTL needs
 a mechanism for providing a standard implementation to multiple



 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

 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



 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




 point.
 Although I find most arguments for language-assisted aggregation




 unconvincing, that may well be just because of the way I program, or




 type of
 programs I write, or whatever.

 There seems to have been broad agreement for my mixins idea in terms




 how it
 meets the requirements I have. Those requirements are primarily for




 at
 this
 point, but I see it as fundamental to have a widely applicable

 mixin mechanism that may be applied to *anything* that has opApply.

 I'm thinking of the Search class of std.recl, but it applies equally


 to
 other classes.) This would be allow the D equivalent to STLSoft, if




 like, to
 be achievable with a simple ", mixes Ranges" statement in the




 list of
 any class which has opApply().

 As far as aggregation goes, this seems to me to be an entirely




 matter,
 and I respectfully suggest that it be separated out with its own




 and
 keywords. It may well be a widely needed and desired feature, and




 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


 function, as in C++, and then each collection can have a method which


 this function.

Now that's a useful suggestion.
 I also think that multiple inheritance is also not needed. For example,


 does a stream class has to be derived from input stream and output


 just have one stream class with input and output capabilities, and throw


 exception if the stream is not readable or not writable. It's simple, it


 elegant, why mess with it ?

The mixing of input and output is one of my least favourite features of

 class. I think I've seen precisely one example where I+O was needed in one

 in 15 years of programming. I've never written any stream classes where

 joined, and no-one's ever complained.

 The idea of having something that can be either, and finding out at

 whether it is or not is, to put it crudely, crap. Compile-time is always

 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
May 02 2004
next sibling parent Achilleas Margaritis <Achilleas_member pathlink.com> writes:
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



 Inheritance
 (MI) in legacy code. Both idea are coming at it from different



 DTL needs
 a mechanism for providing a standard implementation to multiple



 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

 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



 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




 point.
 Although I find most arguments for language-assisted aggregation




 unconvincing, that may well be just because of the way I program, or




 type of
 programs I write, or whatever.

 There seems to have been broad agreement for my mixins idea in terms




 how it
 meets the requirements I have. Those requirements are primarily for




 at
 this
 point, but I see it as fundamental to have a widely applicable

 mixin mechanism that may be applied to *anything* that has opApply.

 I'm thinking of the Search class of std.recl, but it applies equally


 to
 other classes.) This would be allow the D equivalent to STLSoft, if




 like, to
 be achievable with a simple ", mixes Ranges" statement in the




 list of
 any class which has opApply().

 As far as aggregation goes, this seems to me to be an entirely




 matter,
 and I respectfully suggest that it be separated out with its own




 and
 keywords. It may well be a widely needed and desired feature, and




 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


 function, as in C++, and then each collection can have a method which


 this function.

Now that's a useful suggestion.
 I also think that multiple inheritance is also not needed. For example,


 does a stream class has to be derived from input stream and output


 just have one stream class with input and output capabilities, and throw


 exception if the stream is not readable or not writable. It's simple, it


 elegant, why mess with it ?

The mixing of input and output is one of my least favourite features of

 class. I think I've seen precisely one example where I+O was needed in one

 in 15 years of programming. I've never written any stream classes where

 joined, and no-one's ever complained.

 The idea of having something that can be either, and finding out at

 whether it is or not is, to put it crudely, crap. Compile-time is always

 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.
May 03 2004
prev sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
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?
May 03 2004
parent "Achilleas Margaritis" <axilmar in.gr> writes:
"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.
May 03 2004
prev sibling parent reply Drew McCormack <drewmccormack mac.com> writes:
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
May 05 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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


 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.
May 05 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
May 05 2004
next sibling parent reply Mark T <Mark_member pathlink.com> writes:
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
May 05 2004
parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
"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.


the compiler knows exactly what type something is, it can customize the


for that type.

bingo - choose the right tool for the problem at hand, I can't understand

 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


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.
May 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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.


the compiler knows exactly what type something is, it can customize the


for that type.

bingo - choose the right tool for the problem at hand, I can't understand

 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


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.

May 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c7blsj$2f54$1 digitaldaemon.com...
 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

covered COM's VARIANT as well, although only if it doesn't require _too_ much shoehorning.
 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.


the compiler knows exactly what type something is, it can customize the


for that type.

bingo - choose the right tool for the problem at hand, I can't understand

 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


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.


May 05 2004
parent J C Calvarese <jcc7 cox.net> writes:
Matthew wrote:

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c7blsj$2f54$1 digitaldaemon.com...
 
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

covered COM's VARIANT as well, although only if it doesn't require _too_ much shoehorning.
Maybe the last pre-1.0 feature (along with mixins, of course)?!


A built-in variant! That'd be great! The real way to do variable arguments.
"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

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.



-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 05 2004
prev sibling parent Drew McCormack <drewmccormack mac.com> writes:
On 2004-05-05 19:24:25 +0200, "Walter" <newshound digitalmars.com> said:

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

Right. Why do you think I am using it? ;-) I need something for HPC. If I write a general purpose desktop app, I tend to use a dynamically-typed language like python or obj-c, not c++, and probably not D. But if performance is critical, l think D is about the best you can do in a statically-typed language. Drew
May 06 2004
prev sibling parent reply "Scott Egan" <scotte tpg.com.aux> writes:
HELP!!!  I've been reading some of the threads on mixins.  I'm unfortunately
not 100% sure I understande them.  Can someone give me a 10 line summary?

As for aggregation, in all the com programming I've done, I never came up
with a use for it.



"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

 Although I find most arguments for language-assisted aggregation pretty
 unconvincing, that may well be just because of the way I program, or the

 programs I write, or whatever.

 There seems to have been broad agreement for my mixins idea in terms of

 meets the requirements I have. Those requirements are primarily for DTL at

 point, but I see it as fundamental to have a widely applicable

 mixin mechanism that may be applied to *anything* that has opApply.

 I'm thinking of the Search class of std.recl, but it applies equally well

 other classes.) This would be allow the D equivalent to STLSoft, if you

 be achievable with a simple ", mixes Ranges" statement in the intialiser

 any class which has opApply().

 As far as aggregation goes, this seems to me to be an entirely different

 and I respectfully suggest that it be separated out with its own syntax

 keywords. It may well be a widely needed and desired feature, and should

 (or fall) on its own.

 Just my t'uppence, anyhow.

 Matthew

May 01 2004
parent "Jeroen van Bemmel" <someone somewhere.com> writes:
There is a lot of literature on mixins

I found http://citeseer.ist.psu.edu/bracha90mixinbased.html ( 14 years old )
which defines a mixin as 'an abstract subclass'. The example they give is a
'border' mixin that adds a border to any kind of window class by
subclassing, and state that mixins often specialize a parent class by
implementing some methods and then calling "corresponding" parent methods.
To me, this sounds like a slightly different concept than what has been
discussed in this newsgroup

- Mixins as subclasses would allow additional fields
- This would require syntax constructs independent from the original class
and the mixin class, like this:

class SomeClass {
    void someMethod() { ... }
}

mixin SomeMixin {
   void someMethod() {
      // "overrides" any method defined in parent, then invokes that as a
last action. Choice: implicitly or explicitly
   }
}

// For example: apply mixin when declaring a variable (could be done using
an alias too)
SomeClass:SomeMixin x;

"mixin" would not even need to be a separate keyword; compiler could check
'mixability' at variable declaration time, and report any conflicts as
errors

Difference with "normal" inheritance would be that mixins are abstract, and
cannot be instantiated standalone.


"Scott Egan" <scotte tpg.com.aux> wrote in message
news:c71c0i$1tia$1 digitaldaemon.com...
 HELP!!!  I've been reading some of the threads on mixins.  I'm

 not 100% sure I understande them.  Can someone give me a 10 line summary?

 As for aggregation, in all the com programming I've done, I never came up
 with a use for it.



 "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

 Although I find most arguments for language-assisted aggregation pretty
 unconvincing, that may well be just because of the way I program, or the

 programs I write, or whatever.

 There seems to have been broad agreement for my mixins idea in terms of

 meets the requirements I have. Those requirements are primarily for DTL


 this
 point, but I see it as fundamental to have a widely applicable

 mixin mechanism that may be applied to *anything* that has opApply.

 I'm thinking of the Search class of std.recl, but it applies equally


 to
 other classes.) This would be allow the D equivalent to STLSoft, if you

 be achievable with a simple ", mixes Ranges" statement in the intialiser

 any class which has opApply().

 As far as aggregation goes, this seems to me to be an entirely different

 and I respectfully suggest that it be separated out with its own syntax

 keywords. It may well be a widely needed and desired feature, and should

 (or fall) on its own.

 Just my t'uppence, anyhow.

 Matthew


May 02 2004