Inheritance is the fundamental reuse mechanism in object-oriented programming languages; its most prominent variants are single inheritance, multiple inheritance, and mixin inheritance. In the first part of this paper, we identify and illustrate the conceptual and practical reusability problems that arise with these forms of inheritance. We then present a simple compositional model for structuring object-oriented programs, which we call traits. Traits are essentially groups of methods that serve as building blocks for classes and are primitive units 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.

Inheritance is well-known and accepted as a mechanism for reuse in object-oriented languages. Unfortunately, due to the coarse granularity of inheritance, it may be difficult to decompose an application into an optimal class hierarchy that maximizes software reuse. Existing schemes based on single inheritance, multiple inheritance, or mixins, all pose numerous problems for reuse. To overcome these problems we propose traits, pure units of reuse consisting only of methods. We develop a formal model of traits that establishes how traits can be composed, either to form other traits, or to form classes. We also outline an experimental validation in which we apply traits to refactor a non-trivial application into composable units.

Abstract. 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.

Traits are fine-grained components that can be used to compose classes, while avoiding many of the problems of multiple inheritance and mixin-based approaches. Since most implementations of traits have focused on dynamically-typed languages, the question naturally arises, how can one best introduce traits to statically-typed languages, like Java and C#? In this paper we argue that the flattening property of traits should be used as a guiding principle for any attempt to add traits to statically-typed languages. This property essentially states that, semantically, traits can be compiled away. We demonstrate how this principle applies to Featherweight-Trait Java, a conservative extension to Featherweight Java.

Traits are an object-oriented programming language construct that allow groups of methods to be named and reused in arbitrary places in an inheritance hierarchy. Classes can use methods from traits as well as defining their own methods and instance variables. Traits thus enable a new style of programming, in which traits rather than classes are the primary unit of reuse. However, the additional sub-structure provided by traits is always optional: a class written using traits can also be viewed as a flat collection of methods, with no change in its semantics. This paper describes the tool that supports these two alternate views of a class, called the traits browser, and the programming methodology that we are starting to develop around the use of traits. 1.

Abstract. The Scheme language report advocates language design as the composition of a small set of orthogonal constructs, instead of a large accumulation of features. In this paper, we demonstrate how such a design scales with the addition of a class system to Scheme. Specifically, the PLT Scheme class system is a collection of orthogonal linguistic constructs for creating classes in arbitrary lexical scopes and for manipulating them as first-class values. Due to the smooth integration of classes and the core language, programmers can express mixins and traits, two major recent innovations in the object-oriented world. The class system is implemented as a macro in terms of procedures and a record-type generator; the mixin and trait patterns, in turn, are naturally codified as macros over the class system. 1 Growing a Language The Revised 5 Report on the Scheme programming language [20] starts with the famous proclamation that “[p]rogramming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional

Much of the elegance and power of Smalltalk comes from its programming environment and tools, but despite the passage of more than 20 years, the Smalltalk browser is much the same today as when it was first introduced. We have extended this browser with features that dramatically improve its support for incremental programming by employing real-time analysis of the code being modified. We illustrate these improvements by example, and summarize the algorithms used to implement them efficiently.

Abstract not found

Traits support the factoring out of common behaviour, and its integration into classes in a manner that coexists smoothly with inheritance-based structuring mechanisms.

Traits are reusable units of behaviour that provide a level of structuring for object-oriented programs above the level of methods but below the level of classes. Structuring classes with single-inheritance alone can lead to duplicated code when different branches of the hierarchy need to use the same feature. Multiple-inheritance and mixins alleviate this problem, but lead to other difficulties in the face of evolution: changes to classes or mixins can break code lower in the hierarchy in unexpected ways.