Smalltalk Traits Expressing Themselves
by Peter William Lount
version 1, 20050312 1:32am PST
"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
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
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.
Research Software Composition Group (SCG), University of Berne.
It sounds like traits may be the way to go rather than using multiple inheritance with it's complexities.
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
Quoting from the above paper:
Traits have the following properties.
A trait provides a set of methods that implement behaviour.
A trait requires a set of methods that serve as parameters for the provided behaviour.
Traits do not specify any state variables, and the methods provided by traits never
access state variables directly.
Classes and traits can be composed from other traits, but the composition order is
irrelevant. Conflicting methods must be explicitly resolved.
Trait composition does not affect the semantics of a class: the meaning of the class
is the same as it would be if all of the methods obtained from the trait(s) were
defined directly in the class.
Similarly, trait composition does not affect the semantics of a trait: a composite trait
is equivalent to a flattened trait containing the same methods.
The proposed traits extension is an easy one to understand. I wonder how useful it will be in the long run?
Copyright 1999-2010 by Smalltalk.org, All Rights Reserved.
July 30 2014
On speaking languages
naturally with ease
aiming for fluid fluency.