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


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


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


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.

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


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






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.

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






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






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




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




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.



 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.




 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.





 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.




 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.







 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



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.






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


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





 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


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


 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







 May 02 2004