Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!mtune!codas!usfvax2!pdn!colin
From: colin@pdn.UUCP (Colin Kendall)
Newsgroups: comp.lang.smalltalk
Subject: Re: addition
Message-ID: <1164@pdn.UUCP>
Date: Thu, 27-Aug-87 05:17:29 EDT
Article-I.D.: pdn.1164
Posted: Thu Aug 27 05:17:29 1987
Date-Received: Sat, 29-Aug-87 08:59:36 EDT
References: <245100011@orstcs> <102@laura.UUCP>
Organization: Paradyne Corporation, Largo, Florida
Lines: 72
Summary: what's wrong with testing an object's understanding?


In the debate about coercion vs. multiple polymorphism:

Mostly I agree with Dale Henrichs: They both work fine. However, Dale
says that the argument that multiple polymorphism needs more methods
is not a valid criticism. From a practical standpoint, I have to
disagree: methods use OOPs, so more methods use more OOPs. Source
code for methods uses disk space. Also, recent experience in
debugging and modifying Smalltalk code has taught me that the
fewer methods there are, the easier it is to understand.

What I can't understand is the objection that so many people make to
testing an object's class. It seems to be an ungrounded esthetic
objection, and one which was seemingly not shared by the designers, 
inasmuch as there are about 120 such tests in the original Smalltalk-80
image.

In support of their objection, people cite the famous quotation that
says who cares what an object's class is as long as it understands a
message... but how do you know if it understands a message.

Well, perhaps there is a good reason for the objection. I'd like
to know it. I'd also like to know whether there is a similar objection 
to testing whether an object understands a given message.

To make a perhaps depersonalizing metaphor, suppose I know several
(human) languages, and I am dropped into some foreign country and
wish to communicate with the inhabitants. I could say, "I don't
care what nationality you are, as long as you understand Swahili",
and start speaking in Swahili, but my chances of communicating would
be slim. A more logical approach would be to try various messages,
like "How are you", "Comment allez-vous", "Wie geht's", "Como esta",
etc., until I got a response -- if all else failed, I might start
drawing pictures in the dirt.  What I am doing is saying:

(UnknownPerson respondsTo: #howAreYou) ifTrue: [ ...

Note that I am not explicity testing the person's class (nationality);
if he is a Russian who happens to understand French, I am just as happy.

This is similar to what Martin Mosner is proposing in his example
where he tests if an object understands a sophisticated message,
sends it if so, but if not tests for understanding of a different
(slightly less sophisticated) message, etc. In his example of
an Arc trying to draw itself on a DisplayMedium, if the
DisplayMedium is sophisticated enough to know how to help, it
is asked to do so; else the Arc resorts to more primitive methods.

Testing understanding allows the application of *limited* multiple
polymorphism with or without intermixed coercion. To go back to the example that started all this,
Point>+ could be written:

+ delta

( delta respondsTo: #pointAdd: ) ifTrue: [^ delta pointAdd: self].
( delta respondsTo: #asPoint ) ifTrue: [^ "(same as original code)" ].
( delta respondsTo: #+ ) ifTrue: [ ^ x + delta @ (y + delta) ]

In a system where nothing responded to #pointAdd:, this code would
work; for efficiency, as time and space permitted, the method pointAdd:
could be added to various classes.

Thus:
Multiple polymorphism works, but requires a lot of methods.
Coercion works, but only for things which can be ordered by generality.
Testing understanding works with neither disadvantage.

-- 
Colin Kendall				Paradyne Corporation
{gatech,akgua}!usfvax2!pdn!colin	Mail stop LF-207
Phone: (813) 530-8697			8550 Ulmerton Road, PO Box 2826
					Largo, FL  33294-2826