Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!tektronix!tekcae!daleh
From: daleh@tekcae.TEK.COM (Dale Henrichs)
Newsgroups: comp.lang.smalltalk
Subject: Re: addition
Message-ID: <1033@tekcae.TEK.COM>
Date: Mon, 24-Aug-87 17:33:43 EDT
Article-I.D.: tekcae.1033
Posted: Mon Aug 24 17:33:43 1987
Date-Received: Wed, 26-Aug-87 01:21:58 EDT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 49

>
>So it would seem to me that in this particular case, the
>generality/coersion scheme uses far fewer methods and is easier to
>generalize than the double polymorphism technique.
> ...
>In this particular case, however, the alternative seems worse.

It is a moot point to discuss which method is TRULY better, since both 
techniques result in the right answer.  However, I think it is important to 
emphasize the differences between the two methods.

Generality/coersion does use far fewer methods than multiple polymorphism.  
This in itself is not a valid criticism since the number of methods measures 
nothing more than the number of methods.  

Multiple polymorphism is the more GENERAL technique (i.e., allowing more 
flexibility in dealing with exceptions to the rule).

Generality/coersion depends upon type testing, a subtle but important 
distinction. With subclassing, type testing becomes complicated:

	isMemberOf: tests whether the receiver is the same class as the argument and 
excludes subclasses
	isKindOf: tests whether the receiver is the same class or a sublclass of the 
argument

Either test can cause difficulties in getting the correct behaviour.  If I use 
isMemberOf: in my type checking, then I must be explicit in my test cases for 
each class, including subclasses.  If I use isKindOf: I don't have to be 
explicit about subclasses, except when I want to make exceptions to the test 
for subclasses that deviate from the expected behaviour.  

As an example, the test isInteger is used so that Integer, SmallInteger, 
LargePositiveInteger, and LargeNegativeInteger would be treated identically in 
the tests for generality/coercing within Integer itself.  All other Numeric 
classes use isMemberOf:.  Point does not perform the type checking and as a 
result fails under certain circumstances.

Multiple polymorphism eliminates the type checking problem completely, allowing 
each object to act 'correctly', since the necessary type information is encoded 
in the message selector (i.e., addFloat:).  Subclasses override methods where 
appropriate. 

I don't believe that either alternative is particularly bad (although Point 
should have been implemented correctly).  Given a choice, I would rather live 
with an implementation based on multiple polymorphism than generality/coercing, 
since I can't guarantee that I will never need to extend arithmetic beyond the 
limitations of generality/coercing.

Dale Henrichs