Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!aero!abbott
From: abbott@aerospace.aero.org (Russell J. Abbott)
Newsgroups: comp.lang.smalltalk
Subject: Processor objects vs. data objects
Message-ID: <57069@aerospace.AERO.ORG>
Date: 31 Aug 89 22:12:31 GMT
Reply-To: abbott@itro3.aero.org (Russell J. Abbott)
Organization: The Aerospace Corporation, El Segundo, CA
Lines: 25


Since *anything* can be an object there is nothing to prevent one from
building processor objects that parallel traditional subprograms.  For
example one could define a SquareRoot class whose instances would be
objects with a single defined method squareRoot: aNumber.  

	SquareRoot new squareRoot: 4
	
would return 2.


Is there an argument against this style of programming?  I notice that
in st80, there are processor objects, e.g., the scanner.  An advantage
is that it reduces the clutter that results from putting every kind of
operation into data objects.  That is, one is not stuck with defining
squareRoot as a method inside numbers when one doesn't always need
numbers that can take their own square roots.

Of course if one uses this approach, one's code is likely to look
somewhat more like traditional code.  In fact, couldn't any
traditionally coded program be translated into an object oriented
language in this way with virtually no structural change?

-- 
-- Russ abbott@itro3.aero.org