The Theory of Classification, Part 16: Rules of Extension and the Typing of Inheritance.

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

“…Inheritance is modelled as a kind of record combination, in which extra fields are added to the fields of a parent object to yield the desired union of fields in the child object: child = parent ⊕ extra In the resulting child, fields obtained from the extra extension may replace similarlylabelled fields obtained from the parent, modelling the notion of method overriding. This is assured by the right-handed preference of the ⊕ union with override operator [2,7].…”

“…In the above definition, ⊥ denotes the undefined value and function-call expressions like: father(label) denote the value stored opposite the label in the father object, which is a map from labels to values. This definition uses the type constraint Μ that was introduced in the previous article [7], which says that two record types may be merged if their common fields have the same types. This is sufficient for second-order polymorphic typed inheritance, adopted in the Theory of Classification [7,1].…”

“…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.…”

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 τ.…”