Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!decvax!tektronix!tekcae!daleh
From: daleh@tekcae.TEK.COM (Dale Henrichs)
Newsgroups: comp.lang.smalltalk
Subject: Re: addition
Message-ID: <1041@tekcae.TEK.COM>
Date: Fri, 28-Aug-87 18:45:03 EDT
Article-I.D.: tekcae.1041
Posted: Fri Aug 28 18:45:03 1987
Date-Received: Sun, 30-Aug-87 06:42:09 EDT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 65

>From a practical standpoint, I have to
>disagree: methods use OOPs, so more methods use more OOPs. Source
>code for methods uses disk space. 

I will stand by my statement that method count comparisons are not valid.  On 
some systems, OOPS are a limited resource and we all must deal with the limits 
of disk space and real memory.  In practical terms, I can reduce my method 
count while still increasing my usage of OOPS and disk space.  Therefore, 
counting methods will not help me solve these problems. 
 
> Also, recent experience in
>debugging and modifying Smalltalk code has taught me that the
>fewer methods there are, the easier it is to understand.

As for understandability, I am not so sure that the coercing/generality code in 
Smalltalk is the model of "understandable code".  I agree that in trying to 
understand a specific function, it is easier when there are fewer methods to 
look at.  However, method count is not really the operative factor in 
understanding the code.

Well structured applications (those that distribute responsibility across a set 
of 'logical' classes and implement a 'single function' per method) ARE easier 
to understand and more importantly easier to subclass and use in my own 
applications.

Given two well structured applications and given that ALL other things were 
equal, I too would prefer the one with fewer methods.
	
>
>What I can't understand is the objection that so many people make to
>testing an object's class. 
> ...
>Well, perhaps there is a good reason for the objection. I'd like
>to know it. 

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

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

"Multiple polymorphism" works, and is a general approach to a difficult 
problem.
Coercion works in this specific case, but has limitations as a general 
technique.
Testing understanding works, but seems to be redundant.  

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

Dale Henrichs