CHAPTER 33 Using Mixin Technology to Improve Modularity by Richard Cardone and Calvin Lin In object-oriented languages, aspects can be defined by generalizing the idea of a class to that of a mixin. Mixins, which can be implemented as generic types, become aspects when they contain code for multiple classes. In this chapter, we describe mixins and we explain how mixins can be used to define aspects. We demonstrate the flexibility of mixin programming by prototyping a graphical user interface library that can be configured to run on dissimilar devices. We describe additional language and compiler sup- 1 2 Chapter 33 Using Mixin Technology to Improve Modularity port that increases the effectiveness of mixin programming. We conclude by proposing some new ideas about how mixins, and generic types in general, can be better supported in object-oriented languages. 33.1. INTRODUCTION One approach to reducing the cost of software is to make software easier to reuse and, in doing so, to reduce the risk and expense of developing new ap- plications. If existing software can be reused, then the cost of developing and maintaining new code can be significantly reduced. This ability to reuse code depends on two properties: modularity and easy composition. Modu- larity allows us to separate concerns [26], making code easier to understand, maintain, and treat as a unit. Easy composition allows us to combine the ca- pabilities of different code modules in different applications. Unfortunately, today’s object-oriented languages, such as Java, are lim- ited in their ability to modularize and compose code. Modularity is limited because the basic unit of encapsulation and reuse is the class. Once the or- ganization of a class hierarchy is fixed, it is always possible to define new 33.1. Introduction 3 features whose implementations crosscut the existing set of classes. It is common for features that add global properties, such as security, thread safety, fault tolerance, or performance constraints, to affect code in multiple classes. It is difficult to encapsulate such features in a single class. Instead, object-oriented programs generally consist of sets of collaborating classes [15], and changes to one class often require coordinated changes to others. Current object-oriented languages are also limited in their ability to compose features. Java’s support for composition depends primarily on sin- gle inheritance and subtype polymorphism. These mechanisms do not scale well when there are a large number of features. For example, there are three possible ways to organize two features, A and B, into classes: (1) put them in the same class, (2) make A a subclass of B, or (3) make B a subclass of A. B A A+B A B (1) (2) (3) 4 Chapter 33 Using Mixin Technology to Improve Modularity Each choice has different implications regarding the composition of A and B. For example, the first two choices force B to be included whenever A is in- cluded. Thus, by forcing the programmer to choose a single fixed class hier- archy, Java makes it difficult to compose a collection of features in an or- thogonal manner. As the number of features grows, this problem becomes more severe, because the number of possible feature combinations grows rapidly, but the number of feature combinations that can be practically sup- ported does not. This chapter describes how mixins [8], a kind of generic type, can im- prove the flexibility of Java class hierarchies, thereby improving the ability to modularize code and compose features. The purpose of this chapter is threefold. First, we provide an introduction to mixin programming. We de- scribe our mixin extension to Java and the additional language support that we implemented to increase the effectiveness of programming with mixins. Second, to give a concrete example, we summarize our previously published evaluation [12] of how mixins allow us to build customizable GUI libraries. In particular, we explain how a nested form of mixins, called mixin layers 33.2. Mixin Technology 5 [27] [28], can be used to implement a configurable GUI that runs on plat- forms with widely dissimilar capabilities, such as cell phones, PDAs, and PCs. We also show how mixin layers support the implementation of cross- cutting features, so mixin layers can be thought of as aspects [23]. Third, we propose a new approach of integrating mixins into object-oriented type sys- tems and a new way of reconciling the implementation tradeoffs inherent in parametric polymorphism. 33.2. MIXIN TECHNOLOGY Our approach to increasing reuse is to build into programming languages better support for modularization and composition. To test this approach, we have developed the Java Layers (JL) language [11] [20], which extends the compositional capability of Java. Java Layers extensions include support for constrained parametric polymorphism [10] and mixins. Parametric polymorphism allows types to be declared as parameters to code. Parametric polymorphism enhances reuse by allowing the same generic algorithm to be applied to different types; the 6 Chapter 33 Using Mixin Technology to Improve Modularity collection classes in C++’s Standard Template Library [31] are an example of this kind of reuse. JL’s implementation is similar to C++’s templates, but in keeping with most proposals [1] [9] [19] for adding generic types to Java, JL allows type parameters to be constrained. Mixins are types whose supertypes are specified parametrically. Mix- ins further enhance reuse over non-mixin parametric polymorphism by al- lowing the same subtype specialization to be applied to different supertypes. We give an example of mixin reuse in Section 33.2.1. Mixin layers [27] [28] are a special form of mixins that can be used to coordinate changes in multiple collaborating classes. Mixin layers are mix- ins that contain nested types, which can themselves be mixins. Fidget, our GUI framework described in Section 33.3, is built using mixin layers. 33.2.1 Mixins The term mixin was first used to describe a style of LISP programming that combines classes using multiple inheritance [21] [24]. Since then, the mixin concept has evolved to be that of a type whose supertypes are declared pa- 33.2. Mixin Technology 7 rametrically [8] [32]. We use the term in this sense and limit ourselves to languages such as Java that support single inheritance of classes. JL sup- ports mixins and other generic types by implementing parametric classes and interfaces. Mixins are useful because they allow multiple classes to be specialized in the same manner, with the specializing code residing in a single reusable class. For example, suppose we wanted to extend three unrelated classes– Car, Box and House–to have a “locked” state by adding two methods, lock() and unlock(). Without mixins, we would define subclasses of Car, Box, and House that each extended their respective superclasses with the lock() and unlock() methods. This approach results in replicating the lock code in three places. Using mixins, however, we would instead write a single class called Lockable that could extend any superclass, and we would instantiate the Lock- able class with Car, Box, and House. This approach results in only one defini- tion of the lock code. In JL, the Lockable mixin would be defined as follows: 8 Chapter 33 Using Mixin Technology to Improve Modularity class Lockable<T> extends T { private boolean _locked; public lock(){_locked = true;} public unlock(){_locked = false;} } The above class is parametric because it declares type parameter T. JL’s parametric types are similar in syntax and semantics to C++ template classes. When Lockable<T> is compiled, T is not bound. To use Lockable<T>, T must be bound to a type to create an instantiation of the parametric class. Each distinct binding of T defines a new instantiated type, which can then be used like a conventional Java type. What makes Lockable<T> a mixin, however, is that its instantiated types inherit from the types bound to T. Mixins are distinguished from other pa- rametric types because the supertypes of mixins are specified using type pa- rameters. Thus, a mixin’s supertypes are not precisely known at compile- time, but instead are specified at instantiation-time. Mixin instantiations generate new class hierarchies. For example, Lock- able<Box> generates the following hierarchy: 33.2. Mixin Technology 9 Box Lockable<Box> In its current form, Lockable’s capabilities are limited because nothing can be presumed about the type that gets bound to the type parameter T. In JL, however, constraints can be specified to restrict the types used in instan- tiations. For example, the following redefinition of Lockable guarantees that T’s binding type implements the physical object interface (not shown). This constraint on T means members of PhysicalObject can be used within Lock- able in a type-safe manner. class Lockable<T implements PhysicalObject> extends T {…} 33.2.2 Stepwise Refinement The GenVoca software component model [5] provides a conceptual frame- work for programming with mixins. The model supports a programming methodology of stepwise refinement in which types are built incrementally in layers. The key to stepwise refinement is the use of components, called 10 Chapter 33 Using Mixin Technology to Improve Modularity layers, that encapsulate the complete implementation of individual applica- tion features. Application features are any characteristic or requirement im- plemented by an application. Stepwise refinement allows custom applica- tions to be built by mixing and matching features. Mixins implement GenVoca layers. To see how mixins can be used to build applications incrementally, we define the Colorable and Ownable mixins in the same way that we defined the Lockable mixin above. Colorable man- ages a physical object’s color, and Ownable manages ownership properties. We can now create a variety of physical objects that support various combi- nations of features: Colorable<Ownable<Car>> Colorable<Lockable<Box>> Lockable<Ownable<Colorable<House>>> We can think of each of the above instantiations as starting with the ca- pabilities of some base class, Car, Box or House, and refining those capabilities with the addition of each new feature.