New linked list

[Rémy Mouëza]

It seems that this kind of use of mixins make the term "mixin" inappropriate: it
looks like traits (as on http://www.iam.unibe.ch/~scg/Research/Traits/). A class
has two competing role: being a mold to generate instances and being a mean of
code reuse. The first goal lead to full featured classes, the second to small
sized ones, wich turns to be paradoxal. Traits give a way to address this
problem.

Not that in object engineering litterature, a mixin class is a parameterized
subclass. It can be used to implement some features of aspect oriented
programming.
Mixin classes semantics in D would be : 

template MixinClass ( T )
{
class MyClass : T 
{
this () { super (); }

void foo () { super (); doSomethingMore (); }

void doSomethingMore () { addFeatures (); }
}
}

Mixin classes can create conflicts ( methods having the same signatures ) when
they are composed together. Using named mixins, we can select wich
implementation to use but it would be more interesting to make mixins inherit
from the other composed mixins. As the current scope has precedence over the
mixin code we could do something like ( I never tested it ):

class MyMixedInClass
{
mixin MyClass first ; 
mixin MyClass2 second ;

void doSomethingMore ()
{
second.doSomethingMore (); // Select the priority between mixins.
first.doSomethingMore ();
}
}

Or we could make a feature request to have built in mixin classes, something
like :
mixin class ToBeComposed ( S /* superclass */, /* template params */ ...  )
{  
void feature () { ... }
}

class Composit 
{
mixin !( T ) ToBeComposed ;
mixin OtherMixinClass ;

void feature () 
{ mixin ToBeComposed, OtherMixinClass ; // set mixin precedence.
}
}

The syntax has to be improved but it seems that D has all the features to make
that kind of syntactic sugar. 

BTW, this linked list is a great idea.