As suggested earlier, binary methods cause problems with subtypes because the interpretation of the MyType parameter of the binary method in the subclass is ``smaller'' than the interpretation in the superclass (varies covariantly), in contrast to the rules for subtyping of functions, which require only contravariant changes to parameters. Thus if a class has a binary method, its subclasses will not generate subtypes!
We can make this problem more concrete by showing how our type system
would be unsafe
if we assumed that were a subtype of
.
As expected, the problem arises with a binary method,
. Suppose we write the simple procedure
in Figure
13.
If is of type
, then
has type
=
. Since
also has type
,
type checks
correctly.
Now suppose that we make the call where
is of type
and
is of type
. When the message
is sent to
, a
parameter of type
is expected. Instead the parameter
of type
is provided. When the code of
from class
is executed, first the method
is sent to self, causing no
problems. However the method
is then sent to the actual
parameter
. Because
has no method with this name, the
procedure would crash at this point.
What could have gone wrong? Since the
code of the procedure appears to type check correctly, it must be the
call which is not correct. Here the problem is the assumption
that is a subtype of
! If they were not
subtypes, it would be illegal to make the call of
with
as a parameter.
As a result we see that, unlike the case before we introduced MyType, subclasses no longer need generate subtypes. Thus we will have to come up with a revised definition of subtyping which handles types with MyType correctly.