Notice that the subtype relation depends only on the public interfaces of objects, not their implementations. In particular if one type is a subtype of another, it is not necessary for objects of those types to have arisen from classes that are in the subclass relation. By the same argument, objects of the same type need not have arisen from the same class. They may have been generated by classes with different collections of (hidden) instance variables and method bodies, but whose (visible) methods have the same types. This is similar to the impact of information hiding in programming languages which support abstract data types.
The paper [CHC90] was one of the first to examine typing problems in statically-typed object-oriented languages. One of the key points made in that paper (as reflected in the title) is this distinction between inheritance and subtyping.
Nevertheless, we note that most existing object-oriented programming languages do identify type and class as well as subtype and subclass. That is, a class is identified with the type of objects it generates, while only subclasses generate subtypes. (It is worth noting that some languages, like C++, support a form of private inheritance which does not result in subtypes.) The new language Java provides more separation of types from classes than is usual by providing interfaces which are distinct from the classes which may conform to them.
We believe that it is unfortunate to identify subtyping and inheritance, as types should only refer to the interface of an object, not its implementation. While the analysis of typing in the rest of this paper can be profitably applied to languages which do identify subclass and subtype, our analysis also shows how object-oriented languages could profit from the separation of these notions.