Mixins vs. Traits

Mixins may contain state, (traditional) traits don't. Mixins use "implicit conflict resolution", traits use "explicit conflict resolution" Mixins depends on linearization, traits are flattened.

Lecture about traits

ad 1. In mixins you can define instance variables. Traits do not allow this. The state must be provided by the composing class (=class using the traits)

ad 2. There may be the name conflict. Two mixins (MA and MB) or traits (TA and TB) define the method with the same definition foo():void.

Mixin MA {
    foo():void {
        print 'hello'
    }
}

Mixin MB {
    foo():void {
        print 'bye'
    }
}

Trait TA {
    foo():void {
        print 'hello'
    }
}

Trait TB {
    foo():void {
        print 'bye'
    }
}

In mixins the conflicts in composing class C mixins MA, MB are resolved implicitly.

Class C mixins MA, MB {
    bar():void {
        foo();
    }
}

This will call foo():void from MA

On the other hand while using Traits, composing class has to resolve conflicts.

Class C mixins TA, TB {
    bar():void {
        foo();
    }
}

This code will raise conflict (two definitions of foo():void).

ad 3. The semantics of a method does not depend of whether it is defined in a trait or in a class that uses the trait.

In other words, it does not matter whether the class consists of the Traits or the Traits code is "copy - pasted" into the class.

These pages explain the difference in the D Programming language.

http://dlang.org/mixin.html

http://dlang.org/traits.html

Mixins in this context are code generated on the fly, and then inserted at that point in code during compilation. Quite handy for simple DSLs.

Traits are compile-time external values (rather than code generated from an external source). The difference is subtle. Mixins add logic, Traits add data such as compile-time type information.

Don't know much about Ruby, but hope this helps somewhat.