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.