A typed calculus of traits

2005

Traits support the factoring out of common behaviour, and its integration into classes in a manner that coexists smoothly with inheritance-based structuring mechanisms. We designed the language Chai, which incorporates statically typed traits into a simple Java-inspired base language, and we discuss three versions of the language: Chai1, where traits are only a mechanism for the creation of classes; Chai2 where traits are a mechanism for the creation of classes, and can also introduce types, and Chai3 where traits play a role at runtime, and can can be applied to objects, and change the objects' behaviour. We give formal models for these languages, outline the proof of soundness, and our prototype implementation.

ECOOP 2003--Object- …, 2003

2002

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. Traits solve both problems by factoring out shared behaviour as sets of methods that do not depend on state. Trait composition is symmetric and conflicts must be managed explicitly; this means that changes in the components do not lead to unexpected side effects. This paper presents a formal model of traits, and defines some basic properties of traits and classes. We also model the internal dependencies created by self and super-sends so that we can specify precisely when two classes are equivalent.

ACM Transactions on …, 2006

Lecture Notes in Computer Science, 1999

We develop an imperative calculus that provides a formal model for both single and mixin inheritance. By introducing classes and mixins as the basic object-oriented constructs in a-calculus with records and references, we obtain a system with an intuitive operational semantics. New classes are produced by applying mixins to superclasses. Objects are represented by records and produced by instantiating classes. The type system for objects uses only functional, record, and reference types, and there is a clean separation between subtyping and inheritance.

IFIP International Federation for Information Processing, 2008

Both single and multiple class-based inheritance are often inappropriate as a reuse mechanism, because classes play two competing roles. Namely, a class is both a generator of instances and a unit of reuse. Traits are composable pure units of behavior reuse, consisting only of methods, that have been proposed as an add-on to single class-based inheritance in order to improve reuse. However, adopting traits as an add-on to traditional class-based inheritance is not enough: classes, besides their primary role of generators of instances, still play the competing role of units of reuse. Therefore, a style of programming oriented to reuse is not enforced by the language, but left to the programmer's skills. Traits have been originally proposed in the setting of dynamically typed language. When static typing is also taken into account, the role of unit of reuse and the role of type are competing, too. We argue that, in order to support the development of reusable program components, object oriented programming languages should be designed according to the principle that each software structuring construct must have exactly one role. We propose a realignment of the class-based object-oriented paradigm by presenting programming language features that separate completely the declarations of object type, behavior and generator. We illustrate our proposal through a core calculus and prove the soundness of the type system w.r.t. the operational semantics.

The diverse inheritance mechanisms provided by Smalltalk, Beta, and CLOS are interpreted as different uses of a single underlying construct. Smalltalk and Beta differ primarily in the direction of class hierarchy growth. These inheritance mechanisms are subsumed in a new inheritance model based on composition of mixins, or abstract subclasses. This form of inheritance can also encode a CLOS multiple-inheritance hierarchy, although changes to the encoded hierarchy that would violate encapsulation are difficult. Practical application of mixin-based inheritance is illustrated in a sketch of an extension to Modula-3.

Recent developments in subjectivity, composition technology and novel prototype-based languages demonstrate that dynamic object extension is an essential feature in modern objectorientation. But the total absence of static type systems for dynamic object extension is a major obstacle for its adoption. The key principle of type-safe dynamic object extension is a trade-off between possible assignments and possible extensions. We describe a static type system using specialisation interfaces to refine the notion of subtyping and to limit dynamic extension. We furthermore argue that the introduction of specialisation interfaces in the system opens up a lot of new perspectives in software engineering in general. The type system is proven to be consistent and complete.

Journal of Functional Programming, 1994

To illuminate the fundamental concepts involved in object-oriented programming languages, we describe the design of TOOPL, a paradigmatic, statically-typed, functional, object-oriented programming language which supports classes, objects, methods, hidden instance variables, subtypes and inheritance. It has proven to be quite difficult to design such a language which has a secure type system. A particular problem with statically type checking object-oriented languages is designing typechecking rules which ensure that methods provided in a superclass will continue to be type correct when inherited in a subclass. The type-checking rules for TOOPL have this feature, enabling library suppliers to provide only the interfaces of classes with actual executable code, while still allowing users to safely create subclasses. To achieve greater expressibility while retaining type-safety, we choose to separate the inheritance and subtyping hierarchy in the language. The design of TOOPL has been guided by an analysis of the semantics of the language, which is given in terms of a model of the F-bounded second-order lambda calculus with fixed points at both the element and type level. This semantics supports the language design by providing a means to prove that the type-checking rules are sound, thus guaranteeing that the language is type-safe. While the semantics of our language is rather complex, involving fixed points at both the element and type level, we believe that this reflects the inherent complexity of the basic features of object-oriented programming languages. Particularly complex features include the implicit recursion inherent in the use of the keyword, self, to refer to the current object, and its corresponding type, MyType. The notions of subclass and inheritance introduce the greatest semantic complexities, whereas the notion of subtype is more straightforward to deal with. Our semantic investigations lead us to recommend caution in the use of inheritance, since small changes to method definitions in subclasses can result in major changes to the meanings of the other methods of the class.

2010

The box model is a component model for the object-oriented paradigm, that defines components (the boxes) with clear encapsulation boundaries. Having well-defined boundaries is crucial in component-based software development, because it enables to argue about the interference and interaction between a component and its context. In general, boxes contain several objects and inner boxes, of which some are local to the box and cannot be accessed from other boxes and some can be accessible by other boxes. A trait is a set of methods divorced from any class hierarchy. Traits can be composed together to form classes or other traits. We present a calculus for boxes and traits. Traits are units of fine-grained reuse, whereas boxes can be seen as units of coarse-grained reuse. The calculus is equipped with an ownership type system and allows us to combine coarse-and fine-grained reuse of code by maintaining encapsulation of components.