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 Derek <ddparnell bigpond.com> writes:
On Sun, 2 May 2004 03:54:44 +1000, Matthew wrote:

[snip]

 
 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.


I assume you are referring to *streamed* I-O rather than *random* I-O
classes. I see a number of examples of random I-O methods that would be
combined in a single class.

(eg. RAM, Video, Database, disk files, Telephones, ...)
 
-- 
Derek
May 01 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Derek" <ddparnell bigpond.com> wrote in message
news:1js2pahxwtoed.ata40ar30mx3.dlg 40tude.net...

 On Sun, 2 May 2004 03:54:44 +1000, Matthew wrote:

 [snip]

 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.


 I assume you are referring to *streamed* I-O rather than *random* I-O
 classes. I see a number of examples of random I-O methods that would be
 combined in a single class.

 (eg. RAM, Video, Database, disk files, Telephones, ...)


Good clarification, yes. Thanks. :)

Streamed I+O is just a stupid hack. (Hmm, playing with the order a bit,
I+O+Streams ... eeek! Heresy!!)
May 01 2004
prev sibling 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 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
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 reply Ben Hinkle <bhinkle4 juno.com>  writes:


On Wed, 5 May 2004 10:24:25 -0700, "Walter"
<newshound digitalmars.com> wrote:


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


I remember my dad (a biochemist) wanted to give up Basic and learn C
because he had heard it was "the language". Well as soon as I started
telling him that in C he had to declare his variables before using
them he was shocked and decided it wasn't worth it. He's been happily
using Basic ever since. :-)

On a more serious note JITs are getting more and more advanced and
MATLAB's JIT will compile a given code chunk on the fly with whatever
arguments are being used the most. If you call foo with doubles like
crazy then foo-with-doubles gets JIT'ed. But there is overhead for
keeping track of all that, for sure.



 May 05 2004



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:jt9j90lr5mek4n1aj7js00b76tc145niju 4ax.com...

 On a more serious note JITs are getting more and more advanced and
 MATLAB's JIT will compile a given code chunk on the fly with whatever
 arguments are being used the most. If you call foo with doubles like
 crazy then foo-with-doubles gets JIT'ed. But there is overhead for
 keeping track of all that, for sure.


JITs are getting better and better. But is MATLAB itself written in a JITted
language? is the Java vm written in Java? Is the Python vm written in
Python?

That said, there is nothing preventing D code from being executed via a JIT
rather than a static compiler.



 May 15 2004



  parent reply Billy Zelsnack <billy_zelsnack yahoo.com>  writes:


 JITs are getting better and better. But is MATLAB itself written in a JITted
 language? is the Java vm written in Java? Is the Python vm written in
 Python?
 
 That said, there is nothing preventing D code from being executed via a JIT
 rather than a static compiler.


I think as the language becomes more popular it is bound to happen. I 
bet within a year we'll see D in .NET CLR or as Java byte code. I am 
very excited about the possiblity. While I am blathering on, I'd also 
like to see a raw C or C++ backend for the D compiler. GCC as an option 
is really nice, but it really is not the fastest compiler around.



 May 15 2004



 next sibling parent reply "Greg Vanore" <dazden at.dazden.dot.org>  writes:


"Billy Zelsnack" <billy_zelsnack yahoo.com> wrote in message
news:c85p17$20km$1 digitaldaemon.com...

 I think as the language becomes more popular it is bound to happen. I
 bet within a year we'll see D in .NET CLR or as Java byte code. I am
 very excited about the possiblity. While I am blathering on, I'd also
 like to see a raw C or C++ backend for the D compiler. GCC as an option
 is really nice, but it really is not the fastest compiler around.


I've studied both Java bytecode and ILASM a little.  You won't see D in Java
bytecode, because it is very specific to allowing
only the necessary features that Java has.  In other words, you won't get
delegates or pointers, anything of the like.  You could implement DBC and
what not, but the things that make D appropriate as a systems level language
make it too feature-rich for the JVM.

ILASM, on the other hand, is pretty generic.  And it's easy to run many
languages on top of it.  I was actually hoping that someone besides myself
would start the D.NET project - but it would be great to have a 1.0 compiler
to do testing.

The enterprise software world is slowly noticing D, and with unit testing
and DBC built in, you can expect some MAJOR attention if you get it running
on .NET or in the JVM (although I don't see the latter happening.)

As an aside, I don't suppose there is anyone interested in starting an ILASM
compiler for D with me?



 May 17 2004



  parent reply "Achilleas Margaritis" <axilmar b-online.gr>  writes:


"Greg Vanore" <dazden at.dazden.dot.org> wrote in message
news:c8arf7$atu$2 digitaldaemon.com...

 "Billy Zelsnack" <billy_zelsnack yahoo.com> wrote in message
 news:c85p17$20km$1 digitaldaemon.com...

 I think as the language becomes more popular it is bound to happen. I
 bet within a year we'll see D in .NET CLR or as Java byte code. I am
 very excited about the possiblity. While I am blathering on, I'd also
 like to see a raw C or C++ backend for the D compiler. GCC as an option
 is really nice, but it really is not the fastest compiler around.


 I've studied both Java bytecode and ILASM a little.  You won't see D in


Java

 bytecode, because it is very specific to allowing
 only the necessary features that Java has.  In other words, you won't get
 delegates or pointers, anything of the like.  You could implement DBC and
 what not, but the things that make D appropriate as a systems level


language

 make it too feature-rich for the JVM.

 ILASM, on the other hand, is pretty generic.  And it's easy to run many
 languages on top of it.  I was actually hoping that someone besides myself
 would start the D.NET project - but it would be great to have a 1.0


compiler

 to do testing.

 The enterprise software world is slowly noticing D, and with unit testing
 and DBC built in, you can expect some MAJOR attention if you get it


running

 on .NET or in the JVM (although I don't see the latter happening.)

 As an aside, I don't suppose there is anyone interested in starting an


ILASM

 compiler for D with me?


Well, if D gets ported to .NET, there goes the neighbourhood! the other half
of Earth (i.e. the Unix world) will probably ignore it, since the .NET
libraries (WinForms etc, not the compiler!!!) is Microsoft proprietary code
and it is never gonna be open source.

I hoped D would be an uber-cross-platform language, not ride the Microsoft
board (i.e. something to write the code ONCE, compiled it for on as many
platforms as the D compiler is available, and then happily run it ever
after).



 May 18 2004



 next sibling parent  Billy Zelsnack <billy_zelsnack yahoo.com>  writes:


 Well, if D gets ported to .NET, there goes the neighbourhood! the other half
 of Earth (i.e. the Unix world) will probably ignore it, since the .NET
 libraries (WinForms etc, not the compiler!!!) is Microsoft proprietary code
 and it is never gonna be open source.
 
 I hoped D would be an uber-cross-platform language, not ride the Microsoft
 board (i.e. something to write the code ONCE, compiled it for on as many
 platforms as the D compiler is available, and then happily run it ever
 after).


If someone writes code to be run natively, they won't use the Microsoft 
libraries. Because of that, the code would be cross-platform.

My reason for wanting a .net version is to support safe game-mod 
development on the windows/mono platform (in any .net supported language 
too). I can still native compile for a console, but I would have the 
option of providing a safe .net version.



 May 18 2004



prev sibling  parent reply "Greg Vanore" <dazden at.dazden.dot.org>  writes:


"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8dqaa$235p$1 digitaldaemon.com...

 Well, if D gets ported to .NET, there goes the neighbourhood! the other


half

 of Earth (i.e. the Unix world) will probably ignore it, since the .NET
 libraries (WinForms etc, not the compiler!!!) is Microsoft proprietary


code

 and it is never gonna be open source.


Very true.  If someone decide to use Windows Forms in D, then that person's
code wouldn't be cross platform unless an emulation library existed.  But
there are already cross-platform GUI libraries for .NET, thanks mostly due
to the work on Mono. If one used those, you could write a cross-platform GUI
in D easily - more easily than going straight to native.

Like I said, the optimal scenario is targeting the JVM.  But it doesn't
support delegates, and probably other language features of D (although as of
1.5, it supports generics (templating)).

I mean, I feel the same kind of regret.  One thing that attracted me to D is
its Java-like simplicity, yet systems-level power.  That is in some ways
bypassed when you talk about targeting .NET or the JVM.  On the other hand,
my day job is enterprise software where features like unit testing and DBC
could be used heavily to make better software.  There are tools like
AspectJ, Barter, XDoclet, JUnit, and other that make this possible - but
they are tools built on top of the language, not a part of it.

You may think this good enough, but in that scenario, you have to make a
business case.  Management is skeptical to rely 3rd party tools for anything
we deliver to a client.  Yet if it is built into the language, it easily
opens doors to use it.

Of course, we use Java at my office and not .NET so it's mostly moot, but
still, more exposure for the language will ultimately be a good thing.  If
we can achieve a transparent D ILASM compiler, then it ultimately doesn't
matter.  You can recompile all your D libs to .NET and still use them there,
and your D code can be native or .NET.


 I hoped D would be an uber-cross-platform language, not ride the Microsoft
 board (i.e. something to write the code ONCE, compiled it for on as many
 platforms as the D compiler is available, and then happily run it ever
 after).


I'm assuming you mean uber-cross-platform-which-compiles-natively, otherwise
I'll just suggest Java.



 May 18 2004



  parent  "Walter" <newshound digitalmars.com>  writes:


"Greg Vanore" <dazden at.dazden.dot.org> wrote in message
news:c8dtnl$29as$1 digitaldaemon.com...

 Like I said, the optimal scenario is targeting the JVM.  But it doesn't
 support delegates, and probably other language features of D (although as


of

 1.5, it supports generics (templating)).


Much as I wish I was wrong, there's no practical way D can be brought to the
JVM (for similar reasons as to why there are no C compilers targetting JVM).
Java bytecodes are very specific to the semantics of Java, and have no
capability of doing pointers, nested functions, or stack aggregates. It
can't even do the full set of D's basic types. Of course, one could possibly
implement a DVM in Java and then have D target the DVM, but I bet it would
run 100 times slower than Java.


 Of course, we use Java at my office and not .NET so it's mostly moot, but
 still, more exposure for the language will ultimately be a good thing.  If
 we can achieve a transparent D ILASM compiler, then it ultimately doesn't
 matter.  You can recompile all your D libs to .NET and still use them


there,

 and your D code can be native or .NET.


ILASM is rich enough to support D.



 May 19 2004



prev sibling  parent  Andy Friesen <andy ikagames.com>  writes:


Billy Zelsnack wrote:


 JITs are getting better and better. But is MATLAB itself written in a 
 JITted
 language? is the Java vm written in Java? Is the Python vm written in
 Python?

 That said, there is nothing preventing D code from being executed via 
 a JIT
 rather than a static compiler.


 
 
 I think as the language becomes more popular it is bound to happen. I 
 bet within a year we'll see D in .NET CLR or as Java byte code. I am 
 very excited about the possiblity. While I am blathering on, I'd also 
 like to see a raw C or C++ backend for the D compiler. GCC as an option 
 is really nice, but it really is not the fastest compiler around.


There's also LLVM: http://llvm.cs.uiuc.edu/

GCC can already output LLVM, so D should be able to target it already. 
(hypothetically)

  -- andy



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