Evaluating the use of MyType

  The net gains with the introduction of MyType are substantial. We can now write down the types of methods in classes in such a way that they will automatically change as desired in subclasses. We have also increased the expressibility of the language by making it possible to use inheritance to define subclasses (such as ${\it {DoubleNode}}$) which could not have previously been defined by inheritance. When these new subclasses have binary methods, however, they may not give rise to subtypes.

We did not run into this mismatch between subclass and subtype earlier, because we were not even allowed to write down subclasses when we wished to have binary methods. With the use of MyType, we now can write such subclasses and make very effective use of them in real programs.

As indicated earlier, the paper [CHC90] examined typing problems in object-oriented languages by looking at a typed semantics of object-oriented languages. In that paper the authors provided examples similar to the one shown here that show that subclasses do not always generate subtypes; it also discussed replacing method types by subtypes in subclasses.

It is possible to restrict the use of MyType to only covariant positions (e.g., result types of functions) in order to ensure that subclasses always generate subtypes. Trellis/Owl [SCB+86] imposes essentially this restriction by imposing the requirement that a subclass is legal only if the generated object type is a subtype of that of the superclass. Thus, while allowing subtyping on method types in subclasses, it would not allow the creation of a subclass for a class with binary methods.

However practical experience leads us to consider the support of binary method to be very important. Moreover, since support for binary methods has no impact on the type correctness or subtyping properties of programs or classes that do not contain binary methods, we see no useful reason for banning contravariant occurrences of MyType.

Let us summarize where we are now in the development of a static type checking system for object-oriented languages. We have introduced the type expression, MyType, which is used in methods to stand for the type of the object executing the method. The use of MyType allows us to define methods whose types change automatically in subclasses in order to provide more accurate type information. When a method in a class is overridden in a subclass, its type may be changed to a subtype of what it was in the superclass.

We introduced the notion of matching in order to capture more accurately the relation between the types of objects generated by superclasses and subclasses. If class ${\it {SC}}$ is a subclass of ${\it {C}}$ then the corresponding types are guaranteed to be in the matching relation. The rules for type checking methods in classes allow us to assume self has type MyType and that MyType matches the object type generated by the class. The relatively weak matching assumption on MyType ensures that inherited methods continue to be type correct in subclasses. Assuming that MyType is the same as the object type generated by the class can lead to typing problems in inherited methods in subclasses.

The definition of subtyping is more restricted than the definition of matching. If a class definition contains any contravariant occurrences of MyType, in particular, if the class contains one or more binary methods, subclasses will not generate subtypes.

Moreover, once we have determined that an object's type matches another object type, we can determine a type for the result of sending a message to the object. Thus it turns out that matching, not subtyping, is the most relevant for determining the type of message sending.

The type system of our language is now significantly more expressive than the simple type system with which we started. In particular, we are now able to write the cloning methods which caused us problems in section 3. We can also now define ${\it {DoubleNode}}$ as a subclass of ${\it {Node}}$, as desired earlier. However there remain a few subclasses we would like to write that are still out of our reach because of typing restrictions. These include the circle / color circle example from section 3, and other examples which seem to require covariant changes to the types of instance variables or the parameters of methods in subclass definitions. The use of MyType took care of these examples when the type being changed was that of the objects being defined in the class. In the next section we introduce bounded type parameters, which will allow us to overcome these other problems as well.