Comparison

The central theme in Section  is separating the mechanism of inheritance from the ends it can be used to achieve. As in most cases where there is more than one possible goal, conflicts between goals arise. A language designer who wishes to ensure the correctness of his typing system may choose to restrict inheritance in certain ways [#!meyer:oosc!#,#!weber:correctness!#] to achieve this, which may in turn prevent some programmers from achieving other goals (certain kinds of code inheritance). Alternatively, a programmer may prefer to arrange his classes in a way that best exploits code sharing, which may interfere with a user's ability to cleanly understand and reason about the class hierarchy.

In [#!lalonde:exemplars:89!#], many of these same conflicts are raised. In the end, LaLonde concludes that (arbitrarily many) distinct inheritance hierarchies are needed to separate the different inter-class relationships that are being captured. However, in [#!lalonde:exemplars:89!#], it is the actual conflicts of different inheritance practices that drives the discussion—the goals that drive the practices emerge from the discussion of the conflicts, rather than the other way around.

As mentioned in Section , attempting to apply formal methods in an OO environment forces this problem into the open. Most often, the approach of researchers is to give a formal definition of inheritance that has ``good'' properties, and then restrict inheritance to such uses [#!royer!#,#!weber:correctness!#,#!weber:discipline!#]. In some cases, authors have even recommended separating the inheritance hierarchy used for type checking (i.e., the ``specification'' inheritance hierarchy) from that used for code sharing [#!canning!#]. Unfortunately, few, if any, of these approaches is based on the goals that inheritance is used to achieve—instead, they are often based on a single conception of a ``good'' inter-class relationship. Fortunately, all of these approaches tend to choose ``good'' inheritance relations that ensure modular reasoning is possible.

By focusing on ``what'' programmers and clients want to do with inheritance, instead of simply the ``how'' of the inheritance mechanism itself, one can step back from the problem and gain a slightly different perspective. It is clear that some of the ``whats'' require conflicting properties of the inheritance relationship itself. Perhaps as LaLonde and others have recommended, using distinct hierarchies (or lattices) for separate inter-class relationships is the way to go. Of course, by examining the support needed for each application of inheritance, one will find that there will be unique restrictions and requirements for these distinct lattices. Exploring what those requirements are, and how the lattices should be interrelated, is an area ripe for research.