next up previous contents
Next: Types and Subtypes, Classes Up: Introduction Previous: Why type checking?

Plan of the paper

In the rest of this paper we discuss the complications that arise in designing static type-checking systems for object-oriented languages, and sketch some ways of avoiding these problems by providing more flexible and expressive type systems. Of course we wish to ensure that the resulting systems are type safe.

We begin in section 2 by reviewing briefly the definitions of types, classes, subtypes, and subclasses, and illustrating their uses in object-oriented languages. In section 3 we discuss relatively simple type-checking systems like those in C++, Object Pascal, and Modula-3, in order to see what problems arise with the most obvious type systems. In section 4 we see that we can easily add more flexibility by allowing programmers to replace methods in subclasses by new ones whose types are subtypes of the original.

In many cases this still does not provide enough expressiveness for the type system to capture the programmer's intentions. Thus in section 5 we introduce the type expression MyType which is used to provide a flexible type for self, the receiver of a message. In the following section we introduce the very important notion of matching, a relation similar to, but distinct from, subtyping. The importance of matching will result from the fact that it is much closer to the inheritance ordering than subtyping is, allowing us to type check methods in such a way that they remain type safe when inherited. We discuss problems that arise with subtyping and so-called binary methods in section 7. We then evaluate what the addition of MyType means for the type system in section 8.

In section 9 we introduce a kind of constrained polymorphism called match-bounded polymorphism that allows us to write reusable code that is more flexible in handling objects of different types. In the following section we show how to use this to provide a solution to Eiffel's covariant typing problems. We also briefly discuss Eiffel's link-time system validity check and Bertrand Meyer's recent ``no polymorphic catcalls'' proposal to deal with these problems.

In section 11 we step back to look at the constructs we have introduced with the view of creating a simpler system. This reexamination will lead us to consider the rather radical step of designing a system that dispenses with the notion of subtyping. Instead, matching and type annotations can be used to provide the ability to use values of different types in particular marked contexts. In the final section we provide a summary and discuss related work.


next up previous contents
Next: Types and Subtypes, Classes Up: Introduction Previous: Why type checking?
Kim Bruce
10/28/1998