[comp.lang.smalltalk] Processor objects vs. data objects

abbott@aerospace.aero.org (Russell J. Abbott) (09/01/89)

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

sakkinen@tukki.jyu.fi (Markku Sakkinen) (09/01/89)

In article <57069@aerospace.AERO.ORG> abbott@itro3.aero.org (Russell J. Abbott) writes:
-
-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.
- ...

You don't need _instances_ at all to accomplish this kind of thing:
define "squareRoot" as a _class_ method so you can simply say

	SquareRoot squareRoot: 4

Or define a "MathFunctions" class that has both "squareRoot"
and other class methods.

Disclaimer: I am not a Smalltalk expert,
apologies if this is a standard way of programming
that almost everybody in the ST community uses when appropriate.
Lynn Stein's paper, "Inheritance Is Delegation" (OOPSLA'87),
makes one realise that classes (that is, ordinary classes,
not metaclasses) are the most important and most powerful objects
in Smalltalk-80.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland

fchan@vlsi.waterloo.edu (Francis Chan) (09/02/89)

In article <57069@aerospace.AERO.ORG> abbott@itro3.aero.org (Russell J. Abbott) writes:
>
>Since *anything* can be an object there is nothing to prevent one from
>building processor objects that parallel traditional subprograms. 
> <stuff deleted>
>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?

Yes, I have done something similar (a large rug so I can sweep the
dirt under it, anyone?). But this was due to a time pressure thing
and I didn't want to redesign much of the code. This was not a
significant piece of code but still... It has been redesigned and
recoded since.. but yes traditional programs can be ported with
little or no structural change. However, you gain almost zero
advantages given to you by the object oriented environment since
the traditional style of coding gives little thought towards
something else using its methods or the possibility of having
subclasses. i.e. reusability is essentially down the drain.

>-- Russ abbott@itro3.aero.org

Francis Chan

johnson@p.cs.uiuc.edu (09/04/89)

Russ Abbot asks about classes that model procedures, not abstract
data types.  The best discussion I know on the topic is by Dan Halbert
and Pat O'Brien in the September '87 edition of IEEE Software.  It is
called "Using Types and Inheritance in Object-Oriented Programs".
One thing to note is that by "type" they mean class.  In my opinion,
a type is very different from a class, but that is about our only point
of disagreement.

In general, operations should be implemented as methods, not as classes.
However, there are several places where it is reasonable to make them
classes.  One is where the operation is very complicated, were there
are many ways to implement it, and where these implementations have a
great deal of internal structure.  For example, "compile" can be thought
of as a method in class String that returns a compiled procedure, but
nobody would ever do that.  Compilers are complicated, and usually contain
parsers, symbol tables, code generators, and many other parts.  It is
much more reasonable to make a Compiler class that represents an instance
of an executing compiler.  Smalltalk-80 does this.  However, users almost
never deal with the compiler directly, but instead ask classes to compile
a string and install it as a method.  The class will instantiate a compiler
to do all the hard work, so we end up with both an elegant interface to
the compiler and a nice design for the compiler.

Another place where it is reasonable to implement an operation as a
class is where you will want to reuse that operation for many classes,
many of which are not closely related.  For example, you might want
to sort any kind of sequentiable collection, though contents of the
collection have to have a comparison operation.  Moreover, there are
many different kinds of sorting algorithms, and it seems a bit odd to
put every single one in the same class.  It is probably better to
define a Sorter class and to define the "sort" method as
	Sorter sort: self.
If a particular sorting algorithm is needed then you can easily call it.

Implementing operations as classes is the exception, not the rule.
You should only do it when the alternative is worse.  However, there
are times when it is the best option.

Ralph Johnson - University of Illinois at Urbana-Champaign

kasper@iesd.auc.dk (Kasper Osterbye) (09/06/89)

In article <80500073@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:
>
>Russ Abbot asks about classes that model procedures, not abstract
>data types.  The best discussion I know on the topic is by Dan Halbert
>and Pat O'Brien in the September '87 edition of IEEE Software.  It is
>called "Using Types and Inheritance in Object-Oriented Programs".
>One thing to note is that by "type" they mean class.  In my opinion,
>a type is very different from a class, but that is about our only point
>of disagreement.
>
>In general, operations should be implemented as methods, not as classes.
>However, there are several places where it is reasonable to make them
>classes.  
[Stuff deleted]
>
>Implementing operations as classes is the exception, not the rule.
>You should only do it when the alternative is worse.  However, there
>are times when it is the best option.
>
>Ralph Johnson - University of Illinois at Urbana-Champaign

In the Beta language they have unified methods and classes in a single
construct called patterns. This seems to be the right way to solve
this specific problem (or at least one way). For an introduction
to the Beta language one can see ECOOP 88, or Wegner et al. "Research
directions in Object oriented programming".

One of the interesting aspect of this unification is that one gets
inheritance for "methods" as well as for classes (Discussed in a paper
at ECOOP 87 I believe).

Kasper Osterbye, Aalborg Universitycentre, Denmark.

-- 
Kasper Osterbye                     Internet: iesd!kasper@uunet.uu.net
Institute for electronic systems    UUCP: ...!mcvax!iesd!kasper
Strandvejen 19, 9000 Aalborg
DENMARK. (W) +45 98 13 87 88-285  (H) +45 98 37 30 65