"Multiple Inheritence is good, but there is no good way to do it!"
Steve Cook, 1987 OOPLSA panel

Traits are a simple composition mechanism for structuring object-oriented programs. A Trait is essentially a parameterzied set of methods; it serves as a behavioral building block for classes and is the primitive unit of code reuse. With Traits, classes are still organized in a single inheritance hierarchy, but they can make use of Traits to specify the incremental difference in behavior with respect to their superclasses.

Unlike mixins and multiple inheritance, Traits do not employ inheritance as the composition operator. Instead, Trait composition is based on a set of composition operators that are complementary to single inheritance and result in better composition properties.

We have implemented Traits in Squeak, an open-source Smalltalk-80 dialect. In the meantime, Traits have had a significant practical impact and have been ported to various other languages.
- Traits Research Software Composition Group (SCG), University of Berne.

Despite the undisputed prominence of inheritance as the fundamental reuse mechanism in object-oriented programming languages, the main variants— single inheritance, multiple inheritance, and mixin inheritance—all suffer from conceptual and practical problems. In the first part of this paper, we identify and illustrate these problems. We then present traits, a simple compositional model for structuring object-oriented programs. A trait is essentially a group of pure methods that serves as a building block for classes and is a primitive unit of code reuse. In this model, classes are composed from a set of traits by specifying glue code that connects the traits together and accesses the necessary state. We demonstrate how traits overcome the problems arising from the different variants of inheritance, we discuss how traits can be implemented effectively, and we summarize our experience applying traits to refactor an existing class hierarchy.
...
Although multiple inheritance makes it possible to reuse any desired set of classes, a class is frequently not the most appropriate element to reuse. This is because classes play two competing roles. A class has a primary role as a generator of instances: it must therefore be complete. But as a unit of reuse, a class should be small. These properties often conflict. Furthermore, the role of classes as instance generators requires that each class have a unique place in the class hierarchy, whereas units of reuse should be applicable at arbitrary places.
- Traits: Composable Units of Behaviour (PDF)