We present MultiJava, a backward-compatible extension to Java supporting open classes and symmetric multiple dispatch. Open classes allow one to add to the set of methods that an existing class supports without creating distinct subclasses or editing existing code. Unlike the “Visitor ” design pattern, open classes do not require advance planning, and open classes preserve the ability to add new subclasses modularly and safely. Multiple dispatch offers several well-known advantages over the single dispatching of conventional object-oriented languages, including a simple solution to some kinds of “binary method ” problems. MultiJava’s multiple dispatch retains Java’s existing class-based encapsulation properties. We adapt previous theoretical work to allow compilation units to be statically typechecked modularly and safely, ruling out any link-time or run-time type errors. We also present a novel compilation scheme that operates modularly and incurs performance overhead only where open classes or multiple dispatching are actually used. 1.

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.

One promising approach for adding object-oriented (OO) facilities to functional languages like ML is to generalize the existing datatype and function constructs to be hierarchical and extensible, so that datatype variants simulate classes and function cases simulate methods. This approach allows existing datatypes to be easily extended with both new operations and new variants, resolving a longstanding conflict between the functional and OO styles. However, previous designs based on this approach have been forced to give up modular typechecking, requiring whole-program checks to ensure type safety. We describe Extensible ML (EML), an ML-like language that supports hierarchical, extensible datatypes and functions while preserving purely modular typechecking. To achieve this result, EML’s type system imposes a few requirements on datatype and function extensibility, but EML is still able to express both traditional functional and OO idioms. We have formalized a core version of EML and proven the associated type system sound, and we have developed a prototype

This paper proposes a new model of programming, in which the behavior of a program can be defined as separate decision point branches. Allowing more precise expression of the condition determining when a branch should be chosen at a decision point leads to better support for incremental programming. This model can be viewed as a fundamental mechanism underlying both OOP and AOP, which can serve as lower-level building blocks that can be put together into the higher-level constructs present in many AOP systems. 1

Software often goes through a variety of extensions during its lifetime: adding new fields or new variants to a data structure, retroactively creating new type abstractions, and adding new operations on a data structure. As characterized by the extensibility problem, it should be possible to apply any combination of these types of extensions in any order. Mainstream

dutchyn,paullu,duane,bromling£ Mainstream object-oriented languages, such as C++ and Java 1, provide only a restricted form of polymorphic methods, namely uni-receiver dispatch. In common programming situations, developers must work around this limitation. We describe how to extend the Java Virtual Machine to support multi-dispatch and examine the complications that Java imposes on multidispatch in practice. Our technique avoids changes to the Java programming language itself, maintains source code and library compatibility, and isolates the performance penalty and semantic changes of multi-method dispatch to the program sections which use it. We have micro-benchmark and application-level performance results for a dynamic Most Specific Applicable (MSA) dispatcher, a framework-based Single Receiver Projections (SRP) dispatcher, and a tuned SRP dispatcher. Our general-purpose technique provides smaller dispatch latency than programmer-written double-dispatch code with equivalent functionality. 1

Object-oriented code looks different from procedural code. The main difference is the increased frequency of polymorphic calls. A polymorphic call looks like a procedural call, but where a procedural call has only one possible target subroutine, a polymorphic call can result in the execution of one of several different subroutines. The choice is made at run time, and depends on the type of the receiving object (the first argument). Polymorphic calls enable the construction of clean, modular code design. They allow the programmer to invoke operations on an object without knowing its exact type in advance. This flexibility incurs an overhead: in general, polymorphic calls must be resolved at run time. The overhead of this run time polymorphic call resolution can lead a programmer to sacrifice clarity of design for more efficient code, by replacing instances of polymorphic calls by several single-target procedural calls, removing run time polymorphism. This practice typically leads to a m...

We propose a framework to describe type systems with type inference for ML-like languages. Our type systems are parameterized by the type algebras from which types are drawn. Type soundness is proved once-and-for-all under minimal assumptions on the type algebra. Observing that ML-Sub types form a type algebra, we propose a decidable type system for a language a la ML with type inference and polymorphic multi-methods, thus solving a long standing problem. Furthermore, we define a sub-language to express classes (constructors), multi-methods (operators), and their static and dynamic semantics in a consistent manner, independently of the base language.

What infrastructure is needed to support aspect-oriented software development? To the programmer, we must supply aspect-oriented (sub)languages that are based on the constructs and basic syntax that the programmer is most familiar with, as well as facilities for reifying and manipulating the cross-cutting features of immediate concern. At the implementation level, the aspect specifications mu' insinuin themselves into the application proper. Furthermore, the support for aspect specification and integration should not impose a performance penalty on the application at r u time. We are conducting research into dynamic reflective object-oriented language design and implementation that provides a rich infrastructure for the development of aspect-oriented technology. The main concepts that we bring to bear are: Reflection and Dynamism: A program is able to reflect on its structure and behavior, and then modify its behavior. metaobject protocols rely on reflection to present a programmer-modifiable dynamic semantics. Syntactic abstraction: A procedu al, hygienic macro system facilitates implementation of AOP langu age extensions; Dynamic, Optimistic Optimization: Programs do not pay a performance penalty merely for the existence of a metaobject protocol. That is, if part of an application does not makeu se of the abstraction provided by a metaobject protocol, performance is as good as if the metaobject protocol did not exist.

Abstract not found