While class-based object-oriented programming languages provide a flexible mechanism for re-using and managing related pieces of code, they typically lack linguistic facilities for specifying a uniform extension of many classes with one set of fields and methods. As a result, programmers are unable to express certain abstractions over classes. In this paper we develop a model of class-to-class functions that we refer to as mixins. A mixin function maps a class to an extended class by adding or overriding fields and methods. Programming with mixins is similar to programming with single inheritance classes, but mixins more directly encourage programming to interfaces. The paper develops these ideas within the context of Java. The results are 1. an intuitive model of an essential Java subset; 2. an extension that explains and models mixins; and 3. type soundness theorems for these languages. 1 Organizing Programs with Functions and Classes Object-oriented programming languages offer classes, inheritance, and overriding to parameterize over program pieces for management purposes and re-use. Functional programming languages provide various flavors of functional abstractions for the same purpose. The latter model was developed from a well-known, highly developed mathematical theory. The former grew in response to the need to manage large programs and to re-use as many components as possible. Each form of parameterization is useful for certain situations. With higherorder functions, a programmer can easily define many functions that share a similar core but differ in a few details. As many language designers and programmers readily acknowledge, however, the functional approach to parameterization is best used in situations with a relatively small number of parameters. When ...

Object-oriented distributed computing is becoming increasingly important for critical infrastructure in society. In standard object-oriented models, objects synchronize on method calls. These models may be criticized in the distributed setting for their tight coupling of communication and synchronization; network delays and instabilities may locally result in much waiting and even deadlock. The Creol model targets distributed objects by a looser coupling of method calls and synchronization. Asynchronous method calls and high-level local control structures allow local computation to adapt to network instability. Object variables are typed by interfaces, so communication with remote objects is independent from their implementation. The inheritance and subtyping relations are distinct in Creol. Interfaces form a subtype hierarchy, whereas multiple inheritance is used for code reuse at the class level. This paper presents the Creol syntax, operational semantics, and type system. It is shown that runtime type errors do not occur for well-typed programs.

Programming languages offer a variety of constructs to support code reuse. For example, functional languages provide function constructs for encapsulating expressions to be used in multiple contexts. Similarly, object-oriented languages provide class (or class-like) constructs for encapsulating sets of definitions that are easily adapted for new programs. Despite the variety and abundance of such programming constructs, however, existing languages are ill-equipped to support component programming with reusable software components. Component programming differs from other forms of reuse in its emphasis on the independent development and deployment of software components. In its ideal form, component programming means building programs from off-the-shelf components that are supplied by a software-components industry. This model suggests a strict separation between the producer and consumer of a component. The separation, in turn, implies separate compilation for components, allowing a pr...

G-Nets are a type of Petri net defined to support modeling of system as a set of independent and loosely-coupled modules. The modular features of G-Nets provide support for incremental design and successive modification, however the G-Net formalism is not fully object-oriented due to a lack of support for inheritance. In this paper, we introduce extensions to G-Nets to support explicit modeling of inheritance. Bounded buffer examples are used, which we define as subclasses of an unbounded buffer, to illustrate the expressive power of the extended G-Net models. Various forms of inheritance are formalized and discussed in the context of concurrent object-oriented design. In addition, the inheritance anomaly problem is examined and discussed. 1 Introduction A widely accepted software engineering principle is that a system should be composed of a set of independent modules, where each module hides the internal details of its processing activities and modules communicate through well-defi...

We present an operational semantics and type safety proof for multiple inheritance in C++. The semantics models the behavior of method calls, field accesses, and two forms of casts in C++ class hierarchies exactly, and the type safety proof was formalized and machine-checked in Isabelle/HOL. Our semantics enables one, for the first time, to understand the behavior of operations on C++ class hierarchies without referring to implementation-level artifacts such as virtual function tables. Moreover, it can—as the semantics is executable—act as a reference for compilers, and it can form the basis for more advanced correctness proofs of, e.g., automated program transformations. The paper presents the semantics and type safety proof, and a discussion of the many subtleties that we encountered in modeling the intricate multiple inheritance model of C++.

This paper considers an integration of asynchronous communication, virtual binding, and multiple inheritance. Object orientation is the leading paradigm for concurrent and distributed systems, but the tightly synchronized RPC communication model seems unsatisfactory in the distributed setting. Asynchronous messages are better suited, but lack the structure and discipline of traditional object-oriented methods. The integration of messages in the object-oriented paradigm is unsettled, especially with respect to inheritance and redefinition. Asynchronous method calls have been proposed in the Creol language, reducing the cost of waiting for replies in the distributed environment while avoiding lowlevel synchronization constructs such as explicit signaling. A lack of reply to a method call need not lead to deadlock in the calling object. Creol has an operational semantics defined in rewriting logic. This paper considers a formal operational model of multiple inheritance, virtual binding, and asynchronous communication between concurrent objects, extending the semantics of Creol.

Object-orientation supports code reuse and incremental programming. Multiple inheritance increases the power of code reuse, but complicates the binding of method calls and thereby program analysis. Behavioral subtyping allows program analysis under an open world assumption; i.e., under the assumption that class hierarchies are extensible. However, method redefinition is severely restricted by behavioral subtyping, and multiple inheritance often leads to conflicting restrictions from independently designed superclasses. This report presents an approach to incremental reasoning for multiple inheritance under an open world assumption. The approach, based on a notion of lazy behavioral subtyping, is less restrictive than behavioral subtyping and fits well with multiple inheritance, as it incrementally imposes context-dependent behavioral constraints on new subclasses. We formalize the approach as a calculus, for which we show soundness.

Object-oriented programming languages represent an original implementation issue due to the mechanism known as late binding, aka message sending. The underlying principle is that the address of the actually called procedure is not statically determined, at compile-time, but depends on the dynamic type of a distinguished parameter known as the receiver. In statically typed languages, the point is that the receiver’s dynamic type may be a subtype of its static type. A similar issue arises with attributes, because their position in the object layout may depends on the object’s dynamic type. Furthermore, subtyping introduces another original feature, i.e. subtype checks. All three mechanisms need specific implementations, data structures and algorithms. In statically typed languages, late binding is generally implemented with tables, called virtual function tables in C++ jargon. These tables reduce method calls to function calls, through a small fixed number of extra indirections. It follows that object-oriented programming yields some overhead, as compared to usual procedural languages. The different techniques and their resulting overhead depend on several parameters. Firstly, inheritance and subtyping may be single or multiple and a mixing is even possible, as in Java,

been issued as a Research Report for early dissemination of its contents. In view of the transfer of copyright to the outside publisher, its distribution outside of IBM prior to publication should be limited to peer communications and specific requests. After outside publication, requests should be filled only by reprints or legally obtained copies of the article (e.g., payment of royalties). Copies may be requested from IBM T. J. Watson Research Center, P.

We show how finite-state machines can standardize the protocol used by a component object to notify other interested objects of its state changes, resulting in a more effective use of static types to constrain both parties, and a more efficient dissemination of information. The enhanced component specification is called a logical observable entity, or LOE. We address two key issues in effectively applying such a strategy: how to extend subtyping to consider the state machines, and how to ensure some kind of compliance between the state-machine specification and its implementation. This leads to an unusual subtyping predicate for LOEs on the one hand, and a prototype code generation strategy on the other. 1 Introduction When a component object is developed in isolation from its clients, it cannot send messages directly to objects in the client systems since it does not know their actual class names. Instead, a level of indirection must be employed, usually by having the component spec...