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.

MultiJava is a conservative extension of the Java programming language that adds symmetric multiple dispatch and open classes. Among other benefits, multiple dispatch provides a solution to the binary method problem. Open classes provide a solution to the extensibility problem of object-oriented programming languages, allowing the modular addition of both new types and new operations to an existing type hierarchy. This article illustrates and motivates the design of MultiJava and describes its modular static typechecking and modular compilation strategies. Although MultiJava extends Java, the key ideas of the language design are applicable to other object-oriented languages, such as C # and C++, and even, with some modifications, to functional languages such as ML. This article also discusses the variety of application domains in which MultiJava has been successfully used by others, including pervasive computing, graphical user interfaces, and compilers.

Object-oriented systems are able to treat objects indirectly by message passing. This allows them to manipulate objects without knowing their exact runtime type. Behavioral subtyping helps one reason in a modular fashion about such programs. That is, one can reason based on the static types of expressions in a program, provided that static types are upper bounds of the runtime types in a subtyping preorder, and that subtypes satisfy the conditions of behavioral subtyping. We survey various notions of behavioral subtyping proposed in the literature for objectoriented programming. We also sketch a notion of behavioral subtyping for objects in component-based systems, where reasoning about the events that a component can raise is important.

First and foremost I thank my parents for all their love and for teaching me to enjoy learning. I especially thank my wife Katie for her support and understanding through this long and sometimes stressful process. I also thank Katie for insisting on good error messages for G! My advisor, Andrew Lumsdaine, deserves many thanks for his support and guidance and for keeping the faith as I undertook this long journey away from scientific computing and into the field of programming languages. I thank my thesis committee: R. Kent Dybvig, Daniel P. Friedman, Steven D. Johnson, and Amr Sabry for their advice and encouragement. A special thanks goes to Ronald Garcia, Christopher Mueller, and Douglas Gregor for carefully editing and catching the many many times when I accidentally skipped over the important stuff. Thanks to Jaakko and Jeremiah for hours of stimulating discussions and arguments concerning separate compilation and concept-based overloading. Thanks to David Abrahams for countless hours spent debating the merits of one design over another while jogging through the hinterlands of Norway. Thanks to Alexander Stepanov and David Musser for getting all this started, and thank you for the encouragement over the years. Thanks to Matthew Austern, his book Generic Programming in the STL was both an inspiration

Encapsulation in object-oriented languages has traditionally been based on static type systems. As a consequence, dynamically-typed languages have only limited support for encapsulation. This is surprising, considering that encapsulation is one of the most fundamental and important concepts behind object-oriented programming and that it is essential for writing programs that are maintainable and reliable, and that remain robust as they evolve. In this paper we describe the problems that are caused by insufficient encapsulation mechanisms and then present object-oriented encapsulation, a simple and uniform approach that solves these problems by bringing state of the art encapsulation features to dynamically typed languages. We provide a detailed discussion of our design rationales and compare them and their consequences to the encapsulation approaches used for statically typed languages. We also describe an implementation of object-oriented encapsulation in Smalltalk. Benchmarks show that extensive use of objectoriented encapsulation results in a slowdown of less than 15 per cent.

We design a calculus that combines class-based features with object-based ones, with the aim of fitting into a unifying setting the "best of both worlds". In a mixin-based approach, mixins are seen as incomplete classes from which incomplete objects can be instantiated. In turn, incomplete objects can be completed in an object-based fashion. Our hybrid calculus is shown to be useful in some real world scenarios that we present as examples.

Equality-based control-flow analysis has been studied by Henglein, Bondorf and Jørgensen, De-Fouw, Grove, and Chambers, and others. It is faster than the subset-based 0-CFA, but also more approximate. Heintze asserted in 1995 that a program can be safety checked with an equalitybased control-flow analysis if and only if it can be typed with recursive types. In this article we falsify Heintze’s assertion, and we present a type system equivalent to equality-based control-flow analysis. The new type system contains both recursive types and an unusual notion of subtyping. We have s ≤ t if s and t unfold to the same regular tree, and we have ⊥ ≤ t ≤ ⊤ where t is a function type. In particular, there is no nontrivial subtyping between function types.

Abstract. Support for object-oriented programming has become an integral part of mainstream languages, and more recently generic programming has gained widespread acceptance as well. A natural question is how these two paradigms, and their underlying language mechanisms, should interact. One particular design option, that of using subtyping to constrain the type parameters of generic functions, has been chosen for the generics extensions to Java and C#. Certain shortcomings have previously been identified in using subtyping for constraining parametric polymorphism in the context of generic programming. To address these, we propose the expansion of object-oriented interfaces and subtyping to include associated types and constraint propagation. Associated types are type members of interfaces and classes. Constraint propagation allows certain constraints on type parameters to be inferred from other constraints on those parameters and their use in base class type expressions. The paper demonstrates these extensions in the context of Generic C # and presents a formalism proving their safety. The formalism is applicable to other mainstream OO languages supporting F-bounded polymorphism, such as Java. 1

We present an imperative calculus for a class-based language. By introducing classes as the basic object-oriented construct in a -calculus with records and references, we obtain a system with an intuitive operational semantics. Objects are instantiated from classes and represented by records. The type system for objects uses only functional, record, and reference types, and there is a clean separation between subtyping and inheritance. We demonstrate that the calculus is sound and suciently expressive to model advanced language features such as inheritance with method rede nition, multi-level encapsulation, and modular object construction.

Abstract JavaGI is an experimental language that extends Java 1.5 by generalizing the interface concept to incorporate the essential features of Haskell’s type classes. In particular, generalized interfaces cater for retroactive and constrained interface implementations, binary methods, static methods in interfaces, default implementations for interface methods, interfaces over families of types, and existential quantification for interface-bounded types. As a result, many anticipatory uses of design patterns such as Adapter, Factory, and Visitor become obsolete; several extension and integration problems can be solved more easily. JavaGI’s interface capabilities interact with subtyping (and subclassing) in interesting ways that go beyond type classes. JavaGI can be translated to Java 1.5. Its formal type system is derived from Featherweight GJ. 1