Object-oriented programming relies on inter-object aliases to implement data structures and other abstractions. Objects have mutable state, but it is when mutable state interacts with aliasing that problems arise. Through aliasing an object's state can be changed without the object being aware of the changes, potentially violating the object's invariants. This problem is fundamentally unresolvable. Many idioms such as the Observer design pattern rely on it. Hence aliasing cannot be eliminated from object-oriented programming, it can only be managed. Various proposals have appeared in the literature addressing the issue of alias management. The most promising are based on alias encapsulation, which limits access to objects to within certain well-defined boundaries. Our approach called ownership types falls into this category. An object can specify the objects it owns, called its representation, and which objects can access its representation. A type system protects the representation by enforcing a well-defined containment invariant. Our approach is a formal one. Ownership types are cast as a type system using an minor extension to Abadi and Cardelli's object calculus with subtyping. With this formalisation we prove the soundness of our ownership types system and demonstrate that well-typed programs satisfy the containment invariant. In addition, we also provide a firm grounding to enable ownership types to be safely added to an objectoriented programming language with inheritance, subtyping, and nested classes, as well as offering a sound basis for future work. Our type system can model aggregate objects with multiple interface objects sharing representation and friendly functions which access multiple objects' private representations, among other examples, thus over...

The most serious impediment to writing substantial programs in the Java TM programming language is the lack of a genericity mechanism for abstracting classes and methods with respect to type. During the past two years, several research groups have developed Java extensions that support various forms of genericity, but none has succeeded in accommodating general type parameterization (akin to Java arrays) while retaining compatibility with the existing Java Virtual Machine. In this paper, we explain how to support general type parameterization---including both non-variant and covariant subtyping---on top of the existing Java Virtual Machine at the cost of a larger code footprint and the forwarding of some method calls involving parameterized classes and methods. Our language extension is forward and backward compatible with the Java 1.2 language and run-time environment: programs in the extended language will run on existing Java 1.2 virtual machines (relying only on the unparameteri...

Parametric types and virtual types have recently been proposed as extensions to Java to support genericity. In this paper we investigate the strengths and weaknesses of each. We suggest a variant of virtual types which has similar expressiveness, but supports safe static type checking. This results in a language in which both parametric types and virtual types are well-integrated, and which is statically type-safe.

It has been recognized in several works that a slice of behavior affecting a set of collaborating classes is a better unit of reuse than a single class. Different techniques and language extensions have been suggested to express such slices in programming languages. We propose delegation layers, an approach that scales the OO mechanisms for single objects, such as delegation, late binding, and subtype polymorphism, to sets of collaborating objects. Technically, delegation layers combine and generalize delegation and virtual class concepts. Due to their runtime semantics, delegation layers are more flexible than previous compile time approaches like mixin layers.

This paper describes wildcards, a new language construct designed to increase the flexibility of object-oriented type systems with parameterized classes. Based on the notion of use-site variance, wildcards provide a type safe abstraction over different instantiations of parameterized classes, by using ‘? ’ to denote unspecified type arguments. Thus they essentially unify the distinct families of classes often introduced by parametric polymorphism. Wildcards are implemented as part of the upcoming addition of generics to the Java TM programming language, and will thus be deployed world-wide as part of the reference implementation of the Java compiler javac available from Sun Microsystems, Inc. By providing a richer type system, wildcards allow for an improved type inference scheme for polymorphic method calls. Moreover, by means of a novel notion of wildcard capture, polymorphic methods can be used to give symbolic names to unspecified types, in a manner similar to the “open ” construct known from existential types. Wildcards show up in numerous places in the Java Platform APIs of the upcoming release, and some of the examples in this paper are taken from these APIs.

This paper presents a mixin based class and method combination mechanism with block structure propagation. Traditionally, mixins can be composed to form new classes, possibly merging the implementations of methods (as in CLOS). In our approach, a class or method combination operation may cause any number of implicit combinations. For example, it is possible to specify separate aspects of a family of classes, and then combine several aspects into a full-fledged class family. The combination expressions would explicitly combine whole-family aspects, and by propagation implicitly combine the aspects for each member of the class family, and again by propagation implicitly compose each method from its aspects. As opposed to CLOS, this is type-checked statically; and as opposed to other systems for advanced class combination/merging/weaving, it is integrated directly in the language, ensuring a clear semantics and a seamless interaction with the type system. Moreover, the ba...

The expression problem is fundamental for the development of extensible software. Many (partial) solutions to this problem have been proposed in the past, but the question of how to use different, independent extensions jointly has received less attention so far. This paper proposes solutions to the expression problem that make it possible to combine independent extensions in a flexible, modular, and typesafe way. The solutions, formulated in the programming language Scala, are affected with only a small implementation overhead and are relatively easy to implement by hand. 1. The Expression Problem Since software evolves over time, it is essential for software systems to be extensible. But the development of extensible software poses many design and implementation problems, especially, if extensions cannot be anticipated. The expression problem is probably the most fundamental one among these problems. It arises when recursively defined datatypes and operations on these types have to be extended simultaneously. The term expression problem was originally coined by Phil Wadler in a post on the Java-Genericity mailing list [34], although it was Cook who first discussed this problem [9]. His work motivated several others to reason about variants of the problem in the following years [18, 27, 17, 12]. In his post to the Java-Genericity mailing list, Wadler also proposed a solution to the problem written in an extended version of GENERIC JAVA [3]. Only later it appeared that this solution could not be typed. For this paper, we paraphrase the problem in the following way: Suppose we have a datatype which is defined by a Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

We present a static type system for object-oriented languages which strives to provide static typechecking without resorting to dynamic "type casts," restricting what code the programmer can write, or being too verbose or difficult to use in practice. The type system supports bounded parametric polymorphism where the bounds on type variables can be expressed using general recursive subtype or signature constraints, with F-bounded polymorphism and covariant type parameters being special cases. We implemented this type system in the Cecil language and used it to successfully typecheck a 100,000-line Cecil program, the Vortex optimizing compiler. Our experience was very good: dynamically-typed code needed very little rewriting. We also observed several common programming situations that presented a challenge for our type system. We discuss these situations and ways to typecheck them statically. Keywords: Language design, static type systems, F-bounded polymorphism, where clauses, type constraints, type inference, binary methods, Cecil

The virtual class [15] construct was first introduced in the language Beta to provide added expressiveness when used with inheritance. Unfortunately, the virtual class construct in Beta is not statically type-safe. In this paper we show how a generalization of the semantics of object-oriented languages with a MyType construct leads to a variant of virtual classes which needs no run-time checks. This results in an object-oriented language in which both parametric types and virtual classes (or types) are well-integrated, and which is statically type-safe.

. Generic types in programming languages are most often supported with various forms of parametric polymorphism, i.e. functions on types. Within the framework of object-oriented languages, virtual types present an alternative where specic types are derived from generic ones using inheritance rather than function application. While both mechanisms are statically safe and support basic genericity, they have very dierent typing properties, each of them providing for the description of useful relationships, which are not expressible with the other. In this paper we present, through the use of examples, a mechanism for describing generic classes: structural virtual types. This mechanism is essentially a merger of parameterized classes and virtual types and includes the bene ts of both, in particular retaining mutual recursion and covariance of virtual types as well as the function-like nature of parameterized classes. 1 Introduction The term genericity in our use covers the ...