Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.clos
Subject: Re: Is CLOS Object-Oriented ???
Keywords: CLOS
Message-ID: <3786@skye.ed.ac.uk>
Date: 19 Nov 90 20:22:38 GMT
References: <1990Nov15.101847.26285@diku.dk>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Distribution: comp
Organization: AIAI, University of Edinburgh, Scotland
Lines: 84

In article <1990Nov15.101847.26285@diku.dk> marquard@rimfaxe.diku.dk (Morten Marquard) writes:

>                                        I have diskussed this with
>others, and a lot of people do not view CLOS as an object-oriented
>language. 

That's because a lot of people are ideologues.

There's almost a small industry involved in defining "object-
oriented".  Some people are trying to get non-object-oriented
languages in, while others are trying to get languages that aren't
"really" object-oriented out.  Most of the exclusive definitions
do excessive violence to the history of OOP.  (No one dares to
make Smalltalk not be object-oriented, but some people dare to
make languages that don't have classes or that use delegation
rather than inheritance not be object-oriented.)

Anyway, there is a trivial way in which CLOS is not an object-
oriented *language*.  CLOS isn't a language (it's a part of Common
Lisp), so _a fortiori_ it isn't an object-oriented language.

This looks too trivial to mention, but I think some of the other
potential objections to CLOS are just as trivial at heart.

>only the methods can change the state of the object.

Suppose I take an object-oriented language and add a new way to
modify the state of an object?  Does the language suddenly cease
to be object-oriented?  If this is the way you think, CLOS will
not be object-oriented, because one can do a SETF of SLOT-VALUE.

But, just as we can allow that CLOS is object-oriented even though
the whole language (Common Lisp) is not (this is the dual of CLOS
not being a language on its own), we can allow that CLOS is object-
oriented even though there are some "dubious" additional features
in the CLOS part of CL.

This gets us, I think, the more serious objections.

>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, eq. a
>generic function can change the state of an object, without the object
>itself knowing it is has been changed!

It is not clear to me what it means for an object to "know" it has
been changed.  Its state will change, and the methods will see the
new state.  Is that not good enough?

As for methods not being "owned", suppose we forget about multi-
methods for the moment.  Then, except for questions of storage
efficiency, an object could contain all methods that could ever
be applied to it.  Can we agree that this is object-oriented?
I hope so.

For all objects of the same class, however, we may as well store all
the methods in one place.  We could store them all in the class,
indexed by message name -- or in something associated with the message
name, indexed by class.  Let's do the latter, and make the "something"
be a (generic) function that sends the corresponding message.

Note that these changes are straightforward, and it's hard for me at
least to see why they'd make the resulting system no longer be object-
oriented.  (Of course, arbitrary changes might make it cease to be
object-oriented, but these aren't arbitrary changes.)

Now we can make a further generalization.  The method is selected 
by looking at the class of the first argument to the (generic)
function.  Why not look at the other arguments too?  If we do that,
as CLOS does, we have multi-methods.

At this point, it is harder to think of the methods as being part of
the objects and of the objects as interpreting messages sent to them,
but it is still a fairly straightforward generalization of such a
system.  If this generalization makes CLOS not be object-oriented,
then I would still say CLOS minus multi-methods is object-oriented.
In my view, however, having this additional capability does not negate
the essentially object-oriented nature of CLOS (just as having ways
other than via methods to change the state did not).

-- jeff