Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mtune!codas!usfvax2!pdn!colin
From: colin@pdn.UUCP
Newsgroups: comp.lang.smalltalk
Subject: Re: addition
Message-ID: <1230@pdn.UUCP>
Date: Wed, 2-Sep-87 06:41:08 EDT
Article-I.D.: pdn.1230
Posted: Wed Sep  2 06:41:08 1987
Date-Received: Fri, 4-Sep-87 03:39:48 EDT
References: <1041@tekcae.TEK.COM>
Organization: Paradyne Corporation, Largo, Florida
Lines: 48

In article <1041@tekcae.TEK.COM>, daleh@tekcae.TEK.COM (Dale Henrichs) writes:
>Given an isolated application with a specific goal, there is no valid objection
>to explicitly testing an object's class.  However, one of the major advantages 
>of using Object-Oriented languages is that once I've implemented some behaviour
>in a class, I have the opportunity to use that behaviour in ANOTHER 
>application, either by using the class as is, or subclassing it and modifying 
>the behaviour slightly.  Explicit type checking reduces the utility of a class,
>since I may have to 'unnecessarily' subclass in order to override the type 
>checking...  

You may have to, but you may not. It seems equally likely that if you
have a behaviour which includes the message: self printString, you may
have to 'unnecessarily' subclass in order to override the self-printing,
if the printing behavior is not desired in the other application.
The logical extension of this is that any action reduces the utility of
a class, since overrides may be needed by related applications; so the
ideal method would do nothing.

>If you are writing an application (such as an arithmetic package),  message 
>testing is unnecessary, since you SHOULD implement the capability in a 
>consistent manner across all classes involved, in which case, all numeric 
>objects would either respond to asPoint OR  pointAdd:.  It isn't necessary to 
>handle both casks.  One of the nice things about 
>Object-Oriented languages is that this type of checking isn't NECESSARY.  The 
>system will tell you that asPoint is not understood, in which case a mistake 
>has been made; either asPoint was not implemented where it should have been, or
>you have just tried to add 1@1 to a Symbol.

Agreed. The point>+ method I described was intended to portray the
methodology only. I would not actually use it in this case, where, as
Dale says, if the argument doesn't understand asPoint a mistake has been
made. I use it only when the arguments are not expected in advance to
be of any particular class, which happens a lot.
One of the nice things about 
Object-Oriented languages is that it allows you to do this type of checking,
and take appropriate action based on the results. 







-- 
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