From: riks@ogicse.ogi.edu (Rik Fischer Smoody)
Newsgroups: comp.object
Subject: Can AX substitute for A?
Keywords: signature
Date: 14 Sep 92 23:37:01 GMT
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

In article <5740@osc.COM> Joe Keane <jgk@osc.com> writes:
>Suppose that there are well-known classes A and B, and a method M which
>operates on instances of both.  Initially there is an implementation for
>M(A,B) and we want to see how people can override this implementation.  Now
>suppose that person X makes a class AX which is a subclass of A.  Then he can
>write a new implementation for the combination M(AX,B).  Similarly, person Y
>makes a class BY which is a subclass of B, and also writes an implementation
>for the combination M(A,BY).
>
>So what happens when the method M is called with the combination M(AX,BY)?
>There can't be a specific implementation for this combination, because no one
>knows about both classes AX and BY.  (Of course we could generate code, but we
>need some method for doing that, so this doesn't change anything.)  So we have
>to pick one of the implementations M(A,B), M(AX,B), or M(A,BY).  It seems kind
>of arbitrary.  And in any case, one or both of people X and Y is going to be
>confused because his implementation didn't get run even though the arguments
>seem to be of the correct type.
I try various bindings to the familiar world.  I am lead to the conclusion 
    that the new objects are probably going to have to be introduced. 
    That might happen the first time someone wants to M an AX and a BY...
   and they might not have created either of AX or BY.
    There is no guaranteeing that it will work.
Let's start with fasten(screw, hole-in-the-wood).  We could substitute a 
    nail...then we normally just whack it with a hammer instead of turning 
    it (yes, I know you can drive screws IN with a hammer, but play along).  
    Or, we could put a nut in the hole (or on the other side) so that the 
    screw is held in with steel threads instead of wood fibers.  But if we try 
    to drive nails into our nuts, we will be unhappy with the result.
From grade school physical science: we can mix(gasoline,alcohol).  NOT 
    drinking and driving, but by adding some Heet(tm) gas treatment which 
    is mostly alcohol to our tank. We can substitute water for the gasoline: 
    alcohol and water mix nicely (the resulting mixture tastes much better, 
    too).  You can substitute oil for alcohol: many small engines require 
    that you mix oil with the gasoline (but don't drink it).  But oil and 
    water do not dissolve each other satisfactorily.
In the above, don't get side-tracked by the unlikely "sub-classing".  
    Whether an object of class B can fill in for one of class A in some 
    context is only coincidental with inheritance.
    Let's please keep code sharing at least partially separated from appropriateness
    for a given context.
Besides, ANY accurate model of the above systems would show the incompatibility
The conclusion I draw is that the programming environment should NOT 
    promote  computer-guessed substitutability.  If it just so happens that 
    the new kinds of objects CAN use an existing method, that's gravy. It 
    should be easy to say which existing method.
Newsgroups: comp.object,comp.software-engineering