It has been pointed out that inheritance and synchronization constraints in concurrent object systems often conflict with each other, resulting in inheritance anomaly where re-definitions of inherited methods are necessary in order to maintain the integrity of concurrent objects. The anomaly is serious, as it could nullify the benefits of inheritance altogether. Several proposals have been made for resolving the anomaly; however, we argue that those proposals suffer from the incompleteness which allows room for counterexamples. We give an overview and the analysis of inheritance anomaly, and review several proposals for minimizing the unwanted effect of this phenomenon. In particular, we propose (partial) solutions using (1) computational reflection, and (2) transactions in OOCP languages. 1 Introduction Inheritance is the prime language feature in sequential OO (Object-Oriented) languages, and is especially important for code re-use. Another important feature is concurrency; although...

This paper describes the Active Object pattern, which decouples method execution from method invocation in order to simplify synchronized access to an object that resides in its own thread of control. The Active Object pattern allows one or more independent threads of execution to interleave their access to data modeled as a single object. A broad class of producer/consumer and reader/writer applications are wellsuited to this model of concurrency. This pattern is commonly used in distributed systems requiring multi-threaded servers. In addition, client applications, such as windowing systems and network browsers, employ active objects to simplify concurrent, asynchronous network operations.

Abstract not found

In order 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 type-checking 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. In order to achieve greater expressibility while retaining type-safety, we choose to separate the inheritance and subtyping hierarchy in the language. The design of...

One of the most intriguing—and at the same time most problematic—notions in object-oriented programming is inheritance. Inheritance is commonly regarded as the feature that distinguishes object-oriented programming from other modern programming paradigms, but researchers rarely agree on its meaning and usage.

Two major obstacles hindering the wider acceptance of multi-methods are concerns over the lack of encapsulation and modularity and the absence of static typechecking in existing multi-method-based languages. This paper addresses both of these problems. We present a polynomial-time static typechecking algorithm that checks the conformance, completeness, and consistency of a group of method implementations with respect to declared message signatures. This algorithm improves on previous algorithms by handling separate type and inheritance hierarchies, abstract classes, and graph-based method lookup semantics. We also present a module system that enables independently-developed code to be fully encapsulated and statically typechecked on a per-module basis. To guarantee that potential conflicts between independently-developed modules have been resolved, a simple well-formedness condition on the modules comprising a program is checked at link-time. The typechecking algorithm and module system are applicable to a range of multi-method-based languages, but the paper uses the Cecil language as a concrete example of how they can be applied.

The notions of class, subclass and virtual procedure are fairly well understood and recognized as some of the key concepts in object-oriented programming. The possibility of modifying a virtual procedure in a subclass is a powerful technique for specializing the general properties of the superclass. In most object-oriented languages, the attributes of an object may be references to objects and (virtual) procedures. In Simula and BETA it is also possible to have class attributes. The power of class attributes has not yet been widely recognized. In BETA a class may also have virtual class attributes. This makes it possible to defer part of the specification of a class attribute to a subclass. In this sense virtual classes are analogous to virtual procedures. Virtual classes are mainly interesting within strongly typed languages where they provide a mechanism for defining general parameterized 1 classes such as set, vector and list. In this sense they provide an alternative to generics. Although the notion of virtual class originates from BETA, it is presented as a general language mechanism.

Abstract not found

Re-use of synchronization code in concurrent OOlanguages has been considered difficult due to inheritance anomaly, which we minimize with our new proposal. Designed with high practicality in mind, we propose language primitives (plus their implementation) with the following characteristics: (1) it allows multiple synchronization schemes---the language schemes for programming synchronization---to coexist and be integrated, (2) re-use of synchronization code is done similarly to sequential OO-languages for user familiarity, (3) it offers high degree of encapsulation---even synchronization schemes could be encapsulated in superclasses in many cases, and (4) it can be efficiently implemented on conventional MPPs. We demonstrate the effectiveness of our proposal with solutions to the example inheritance anomaly cases from [16]. We also give an overview of the implementation architecture, along with preliminary benchmarks. The proposed language primitives are being incorporated into our AB...

iii To Cindy,