Other typing problems

In both of the examples above, the problem types in methods have been the type of the object being defined. While this is an extremely important special case, there are other examples where a type should be changed in a subclass, but the original and revised types are different from that corresponding to the class being defined. This often arises when we have objects with components. For example, suppose we have a circle class with a ${\it {getcenter}}$method which returns a point. If we define a subclass that represents a color circle, it would be natural to wish to redefine ${\it {getcenter}}$to return a color point. This would be illegal by the rules on method types in these object-oriented languages. We wish to have a typing system that allows such changes, as long as they are type safe.

In this section we illustrated several problems with simple type systems. In each case the difficulty arose from a desire to change the types of methods which are modified in subclasses. However no changes to the types of methods are allowed in these type systems. In order to alleviate this rigidity in the simple systems, in the next section we allow more flexibility in the type system by supporting some disciplined changes to types of methods in subclasses. This will solve simple problems like those arising in the circle and colored circle classes. However, more extensive changes will be required to take care of examples involving the deep and shallow clone methods and with the ${\it {Node}}$ and ${\it {DoubleNode}}$ classes.