Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!unido!laura!hmm
From: hmm@laura.UUCP (Martin Mosner)
Newsgroups: comp.lang.smalltalk
Subject: Re: addition
Message-ID: <102@laura.UUCP>
Date: Sat, 22-Aug-87 19:29:10 EDT
Article-I.D.: laura.102
Posted: Sat Aug 22 19:29:10 1987
Date-Received: Sun, 23-Aug-87 21:44:38 EDT
References: <245100011@orstcs>
Reply-To: hmm@unido.UUCP (Hans-Martin Mosner)
Organization: University of Dortmund, W-Germany
Lines: 78

In article <245100011@orstcs> budd@orstcs.cs.ORST.EDU writes:
>
>Let me put in my ha'pennys worth here (inflation may have raised its value
>to two cents by now, but certainly no more than that).
>
... a lot of arguments why coercion is a Good Thing.
>
>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.

I think that for the numerical classes in Smalltalk, where there is
a clear generality order, this scheme is very useful.  It's also
easily extendable as long as the extensions fit in the linear
generality order.  I have done that for complex numbers (which are
trivial) and for some kind of symbolic formulae which were able to
give a graphical representation of themselves.
There are, however, things which are not so linearly structured.
Sorry, I don't have a good example handy.  The only other set of classes
in smalltalk-80 which can easily be interchanged and would thus be
usable as an example are the Collection subclasses, and in this case
compatability is ensured by providing a small number of common
messages which are understood by every Collection.  The same is (at least
theoretically) true for the DisplayObject subclasses.

Is the following idea completely flawed ?
When designing a set of interchangeable classes, first define a
set of basic common behavior.  Now the interaction between the
instances of different classes can use special messages when they
are available, otherwise they fall back to using the primitive
operations.  Let me give an example:
I want to extend the DisplayObject/DisplayMedium class tree.
Currently, DisplayMedium has only Form as a subclass (this is
from memory, I may be wrong).  Assume for a moment that there
are others, like PostscriptPage and VectorDisplay and what else.
All subclasses of DisplayMedium should provide methods for
dsplayin solid rectangles and lines (this is very close to
reality).  However, some DisplayMedia are able to draw circles,
splines and what-have-you.  Now there are some DisplayObjects,
namely Circle & Arc.  These should of course use the special
facilities whenever available.  But they should also be able
to display themselves using only the line drawing operation.

Consider the following method in class Arc:
(Arcs have a radius, start & stop angles and a brush in this example)

displayOn: aDisplayMedium at: centerPoint

    (aDisplayMedium class understands: #drawArcCenter:radius:start:stop:brush:)
	ifTrue: [aDisplayMedium
			drawArcCenter: aPoint
			radius: radius
			start: start
			stop: stop
			brush: brush]
	ifFalse: ["check if aDisplayMedium can draw splines.
		This may result in smoother drawing"
	    (aDisplayMedium class understands: #drawSplinePoints:brush:)
		ifTrue: ["use a spline to draw an approximation"]
		ifFalse: ["draw the arc using drawLineFrom:to:brush"]]

The main point here is that all knowledge about Arc drawing is kept in
the Arc where it belongs.  The special methods in the DisplayMedium
subclass just use special facilities, like the Postscript arc
operator or some hardware arc generator.

This example is realistic, but of course relatively simple.
Question: Is this concept applicable to non-trivial cases as well ?

>
>--tim budd	budd@cs.orst.edu, {hp-pcd,tektronix}!orstcs!budd
>
>p.s. Version two of Little Smalltalk should be posted to comp.src.unix
>in a few days.  Look for it.
I will definitely be looking...

	Hans-Martin Mosner
	...!seismo!unido!hmm, hmm@unido.uucp, hmm@unido.bitnet
D