read the one page description in the paper
http://www.iam.unibe.ch/~scg/Archive/Papers/ 
Duca05ySafeMetaclassTrait.pdf

Traits [11] are an extension of single inheritance with a similar  
purpose as mixins but avoiding their problems. Traits are essentially  
groups of methods that serve as building blocks for classes and are  
primitive units of code reuse. As such, they allow one to factor out  
common behavior and form an intermediate level of abstraction between  
single methods and complete classes. A trait consists of provided  
methods that implement its behavior, and of required methods that  
parameterize the provided behavior. Traits cannot specify any instance  
variables, and the methods provided by traits never directly access  
instance variables. Instead, required methods can be mapped to state  
when the trait is used by a class. With traits, the behavior of a class  
is specified as the composition of traits and some glue methods that  
are implemented at the level of the class. These glue methods connect  
the traits together and can serve as accessor for the necessary state.  
The semantics of such a class is defined by the following three rules:
• Class methods take precedence over trait methods. This allows the  
glue meth
ods defined in the class to override equally named methods provided by  
the traits.
• Flattening property. A non-overridden method in a trait has the same  
semantics as the same method implemented in the class.
• Composition order is irrelevant. All the traits have the same  
precedence, and hence conflicting trait methods must be explicitly  
disambiguated. Because the composition order is irrelevant, a conflict  
arises if we combine two or more traits that provide identically named  
methods that do not originate from the same trait. Traits enforce  
explicit resolution of conflicts by implementing a glue method at the  
level of the class that overrides the conflicting methods, or by method  
exclusion, which allows one to exclude the conflicting method from all  
but one trait. In addition traits allow method aliasing. The programmer  
can introduce an additional name for a method provided by a trait to  
obtain access to a method that would otherwise be unreachable, for  
example, because it has been overridden. Traits can be composed from  
subtraits. The composition semantics is the same as explained above  
with the only difference being that the composite trait plays the role  
of the class.


Look at the trait example in the Ecoop paper and there is a example  
TComplex in the distribution.





Stef




On 11 mars 05, at 10:13, Blake wrote:

> On Fri, 11 Mar 2005 09:28:17 +0100, <goran.krampe at bluefish.se> wrote:
>
>> 	- A tutorial. :) Making some traits, combining them into a class etc,
>> worked just fine - but it would be great with a tutorial that actually
>> went through all the mechanims including aliases and exclusions etc.  
>> But
>> I guess there is no good point in making a tutorial until the UIs are
>> there.
>
> I'd like to do a traits tutorial based on the previously discussed  
> MUD. Traits seem perfect for a D&D style ruleset: All the creatures  
> fit into one or more classes (animal, undead, aberration, etc.). It  
> makes a good compare and contrast, too: there are a lot of shenanigans  
> involved in trying to shoehorn that into traditional inheritance  
> rules. (I once set up a Nethack-type game as a means to teach OO, so  
> this is pretty familiar territory for me.)
>
> What I lack is a good, simple starting framework for setting the  
> tutorial in. :-/
>