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