The Theory of Classification Part 17: Multiple Inheritance and the Resolution of Inheritance Conflicts.

Abstract

INTRODUCTIONThis is the seventeenth article in a regular series on object-oriented theory for nonspecialists. Using a second-order λ-calculus model, we have previously modelled the notion of inheritance as a short-hand mechanism for defining subclasses by extending superclass definitions. Initially, we considered the inheritance of type [1] and implementation [2] separately, but later combined both of these in a model of typed inheritance [3]. By simplifying the short-hand inheritance expressions, we showed how these are equivalent to canonical class definitions. We also showed how classes derived by inheritance are type compatible with their superclass. Further aspects of inheritance have included method combination [4], mixin inheritance [5] and inheritance among generic classes [6].Most recently, we re-examined the ⊕ inheritance operator [7], to show how extending a class definition (the intension of a class) has the effect of restricting the set of objects that belong to the class (the extension of the class). We also added a type constraint to the ⊕ operator, to restrict the types of fields that may legally be combined with a base class to yield a subclass. By varying the form of this constraint, we modelled the typing of inheritance in Java, Eiffel, C++ and Smalltalk. Object-oriented languages vary widely in their policies on inheritance. Some, like Smalltalk, Objective C and Java, only support single inheritance, whereby a class may have at most one parent class. Others, like Flavors, Eiffel, CLOS and C++, support multiple inheritance, whereby a class may have possibly many parent classes. In this article, we consider first the theoretical issues raised by combining multiple implementations. Then, we consider what it means for an object to belong to multiple parent classes, defining the notion of multiple classification.

MontiCore: a framework for compositional development of domain specific languages

“…A well-known problem of multiple inheritance is name clashes when different supergrammars use the same production names. See for example [60] for a discussion on the possibilities to resolve these problems for object-oriented programming languages. For the MontiCore grammar format we decided to use the following solution: in the case that two or more supergrammars share a common production name, the new production must be a subtype and thus contain all elements of all productions with that name in the supergrammars.…”

The Theory of Classification Part 20: Modular Checking of Classtypes.

“…So, this mechanism is adequate to handle specialisation (when a polymorphic type is replaced by a more restricted polymorphic type [9]) and also the kind of symmetrical type-merger that happens with multiple inheritance (when the polymorphic types of two parent classes become unified in the child [10]). The latter case also extends to languages with a combination of single inheritance and multiple interface satisfaction (the λ-calculus model treats all class-like and interface-like types in the same way).…”

“…In earlier articles dealing with inheritance and multiple inheritance, we called this an intersection type [9,10] because the type variable τ is being constrained to accept two different, overlapping sets of types and therefore accepts the intersection of these sets. Accordingly, we used τ <: F[τ] ∧ G[τ] to denote an intersection on the parameter τ.…”

Bridging Concrete and Abstract Syntax of Web Rule Languages

“…During the implementation of the injection and transformation from the R2ML XML to the R2ML metamodel, we noticed the well-known "diamond" problem [17], i.e. a multiple inheritance conflict, in the object-oriented paradigm.…”