Types in school

type is really abstract , or any other mistake related with this construction. Moreover, it mixes up two quite distinct relationships, namely class-subclass and specification-implementation. Finally, al though such use of inheritance can simulate abstract da ta types, it does not separate the specification hierarchy from the implementat ion hierarchy. This confusion between both hierarchies is the source of several misunderstandings on the subject of inheritance. To say that a type A is a subtype of a type B means that A is compatible, from an external point of view, with B. Therefore, an A object can be used wherever a B object is expected. Notice that A and B do not need to have similar implementations. On the other hand, to say that a class A is a subclass of a class B means that A inherits methods and variables from B. As they do not need to have compatible interfaces, A can freely modify the inherited features. Using the classification proposed in [WZ88], subtyping must have behavior compatibility, or at least signature compatibility, while subclassing is free to adopt cancel compatibility. Therefore, there is no compromise between the flexibility of cancel compatibili ty and the security of strong typing. An example may help clarifying that point. A typical use of inheritance is to build a class S tack from a class Array. However, this use of inheritance is sometimes considered a "bad" use, because a stack does not have most array operations 4. If one can define S tack as a subclass of Array , without being a subtype, the problem simply vanishes. S t r u c t u r a l C o m p a t i b i l i t y Usually, in OOPLs, a type is considered a subtype of another one only when it is so declared, directly or through transitivity. The independence between subtyping and subclassing allows a programming language to adopt structural compatibility. That means that a type is a subtype of another one if they are compatible in some way. Following our s tated main rule, we want to allow a type A to be a subtype of B as long as there is no possibility of error when using an A object in the place of B. As errors occur when a message is sent to an object which has no method for it, we can avoid them with the following definition: a type A is a subtype of B (A < B) if and only if, for each method X in B, with ari ty PB1 × . . . X PB, ~ RB1 X . . . X Rsm, there is a method X em A, with arity TAt × . . . × TA, ---~ .RA1 X . . . X R A m , where for all i < m, RA~ -~ RB~ and, for all i < n, Psi "~ PAi . The apparent inversion in the last condition is known as the "counter-variance rule", and is needed to assure correctness [CW85]. A formal definition of subtyping, as well as a formal proof that this definition avoids type errors, can be found in [Ier92]. It is important to notice that this definition is not only sufficient to ensure absence of run-t ime errors, but also necessary. In any language accepting A in place of B with A ~ B, it is possible to write a routine that generates a run-t ime error. As an example of subtyping, consider the declarations: type Pointl method x () r : Integer method y () r : Integer method moveBy (p : Pointl) method copy () p : Pointl end Point1 type Point2 method x () r : Integer method y () r : Integer method moveBy (p : point) 4see, for instance, [KM90]