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

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

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

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

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

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

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

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

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

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