Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!clyde.concordia.ca!s3!gamin
From: gamin@ireq-robot.hydro.qc.ca (Martin Boyer)
Newsgroups: comp.lang.clos
Subject: Re: Is CLOS Object-Oriented ???
Summary: Yes, and more.
Keywords: CLOS
Message-ID: <3904@s3.ireq.hydro.qc.ca>
Date: 15 Nov 90 22:12:34 GMT
References: <1990Nov15.101847.26285@diku.dk>
Sender: root@s3.ireq.hydro.qc.ca
Distribution: comp
Organization: Laboratoire de robotique, Institut de recherche d'Hydro-Quebec
Lines: 77

In article <1990Nov15.101847.26285@diku.dk>,
marquard@rimfaxe.diku.dk (Morten Marquard) writes:
>
>I have a question to all readers of this group:
>    "Is CLOS Object-Oriented ???"
>
>In "normal" object-oriented languages (SmallTalk, C++) an object can
>exist alone. An object consist of a state and a set of methods, and
>only the methods can change the state of the object.
>
>In CLOS an object can be changed by a generic function, in spite of
>the fact that the object does not "own" the generic function [...]

Almost two years ago, I translated some code from Flavors (no doubt
about this one being object-oriented?) to CLOS (well, PCL to be
precise).  I learned the following: if you don't want to know about
generic functions, just forget they exist or, even better, consider
them just as the set of methods sharing the same name.

Then I learned that generic functions "contain" all methods of the
same name and that they discriminate, based on the type of the
arguments, which method is called.

Now, think about it, how is that different from what Flavors used to
do?  The form

(send object message)

can be rewritten without any loss of information as

(message object)

The way I see it, what "send" used to do in Flavors (finding which
method to call and then calling it) is now done in CLOS by the generic
function.

Agreed, it *looks* like we are going back to the old way of doing
things, when functions had to look at the arguments type to decide
what to do with them.  Except that the programmer still writes
methods; all this generic function stuff is done internally.

Now, an example to demonstrate one of the reasons why this
function/object reversal is useful:

Consider the classic

(send square :draw-yourself)

and let's say we want to add some functionality by allowing an extra
argument to indicate where this square should be drawn:

(send square :draw-yourself :on-screen)
(send square :draw-yourself :on-printer)

In Flavors, one would have to re-write the draw-yourself method to
discriminate on the second argument, because the procedure depends on
it.  But wait!  isn't that what "send" was supposed to do in the first
place, discriminate on the first argument to find out which method to
use?  We now need 'draw-yourself' methods specialized on more than one
argument, the object and the medium (as if, in this case, the medium
IS the message :-)).

My conclusion is that methods cannot always be 'owned' by a single
object; if two objects interact, it may not be conceptually sound to
*decide* which object gets the top-level message to then send another
message to the second object.  Perhaps they should *both* receive the
message because the method to use depends on the characteristics of
*both* objects.  This, IMHO, is the major benefit from CLOS; in the
true spirit of OOP, modularity (methods specialized on multiple
arguments) and code re-use (no need for type discrimination inside
methods, for instance).

-- 
Martin Boyer                            mboyer@ireq-robot.hydro.qc.ca
Institut de recherche d'Hydro-Quebec    mboyer@ireq-robot.uucp
Varennes, QC, Canada   J3X 1S1
+1 514 652-8136