Introduction to Eiffel

Multiple inheritance is a big win under Eiffel. If you have dealt with this in other languages you may be surprised. Multiple inheritance entails many sticky problems, including name collisions and complications of repeat inheritance, and in most other languages is best avoided whenever possible.

When two classes inherited by common descendent have different features of the same name, a name collision obtains.

When a feature is inherited more than once from a common ancestor along two or more inheritance paths, you have repeat inheritance. This may cause a name collision and also raises practical problems, such as which repeated feature to use in a polymorphic call.

Most object-oriented languages do not attempt multiple-inheritance. The literature is full of elaborate explanations why. This is sad. Eiffel demonstrates that multiple inheritance need not be difficult or complex, and it can also yield some quite practical results.

Eiffel provides an implementation of multiple inheritance which minimizes the adverse effects of name collisions and repeat inheritance complications. As is typical in Eiffel, the solution to one problem helps solve another problem. In Eiffel, a name inherited from an ancestor may be revised in a descendent using a rename clause. Eliminating name collisions then merely involves giving a new name to one or both of the colliding features. The feature is unaffected, except that it is known in the renaming class and any descendents of that class by its new name.

Supposing we have a class named SOME_OTHER that inherits two entirely different features both called put from two ancestors named FIRST_CLASS and BOWSER:

class SOME_OTHER inherit
   FIRST_CLASS
     rename
       put as first_put
       end;
   BOWSER
     rename
       put as bowser_put
       end;
     ...
end

then in some client class we may have feature what_now:SOME_OTHER

-- We may invoke the feature
-- named put from either of its
-- originating classes

     what_now.first__put(this);
     what_now.bowser_put(that);

Repeat inheritance is only slightly more complex. In the simple case, repeat inheritance is just a by-product of the class inheritance structure you have chosen. Perhaps some of the classes inherited from the class library have common ancestors—this is almost certain. Your responsibility is easy: do nothing. The compiler eliminates the duplicates, and your class has only a single copy of each inherited feature, regardless of how many different ways a feature might come to be present.

In the less common situation, you might want two copies of a feature, for instance put, from an ancestor. A class fragment exhibiting this situation might look something like this:

class SOME_OTHER
     inherit
     FIRST_CLASS
       rename
          put as first_copy
       select
        -- Resolve an ambiguity.
         first_copy
       end;
     FIRST_CLASS
       rename
         put as second_copy
       end;

The select clause serves to resolve an ambiguity. Suppose you reference an object of type FIRST_CLASS and you happen to invoke a feature known in FIRST_CLASS as put.

SOME_OTHER inherits FIRST_CLASS twice, and because of the renaming, there are two possible answers to the question, “What is the name of put in SOME_OTHER?” The following code fragment illustrates:

-- Declare a reference of type FIRST_CLASS
-- then attach an object of type SOME_OTHER,
-- a descendent of type FIRST_CLASS, using a
-- creation procedure of SOME_OTHER called "make"

     this:FIRST_CLASS;
     !SOME_OTHER!this.make;

-- When you try to invoke put,
-- without select it is not clear what you mean.
-- Could mean first_copy, could mean second_copy.

     this.put;

The select clause removes the ambiguity by saying, “When invoking this duplicated feature under its ancestral name, select this copy.” Note that Eiffel brings a thorny problem, repeat inheritance, to the resolution you might hope for. Duplicates are simply eliminated, with no further intervention. If you wish to duplicate-a much less common situation—you can do this using quite simple syntax. Finally, features of the same name that are distinct may be renamed so that both are available, or the unwanted feature may be undefined. pb In each case, the mechanisms provided are simple and local to the class where the problem arises. No revisions to ancestors are required. This is no accident. A major thrust in the design of this language was to eliminate the occasions for revisions to ancestors. Reuse is served here by localizing any adaptations required by repeat inheritance and name collisions in the class where they are encountered. The ancestors are not broken, so they require no fixing. If they are not fixed, they will not have bugs introduced, and other clients or descendents of the ancestor classes will not be affected by changes, bug-inducing or otherwise, that might otherwise be required in the absence of suitable means to resolve conflicts in the descendent.