Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.uucp (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: CLOS: is it OOP?
Message-ID: <944@skye.ed.ac.uk>
Date: 27 Sep 89 14:25:00 GMT
References: <71186@linus.UUCP>
Sender: news@aiai.ed.ac.uk
Reply-To: jeff@aiai.uucp (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 56

In article <71186@linus.UUCP> john@mitre.org writes:
>Wayne Folta writes:
>> ... I have been reading a book which implies that CLOS can be argued
>> to not be OO:
>>
>>"Because CLOS makes no effort at protection or encapsulation, some might
>>find that it lacks the most essential thing for an object-oriented system."
>>
>>"Generic functions are a step away from the concept of active data and back
>>toward the conventional division between passive data and active process."

I haven't seen Wayne Folta's message (or at least not yet).  Can
anyone tell me what book it was?

To me, this looks like a case of Lisp's pragmatic approach running up
against a (from this pragmatic point of view) more ideological approach.
(Like most generalizations, though, this one isn't quite true.  There
was a debate within the Lisp community about the importance of
encapsulation and the significance of 'send' as opposed to generic
functions.)

In what I call the pragmatic view, the difference between

   (<operation name> <instance> <arg>*)

and

   (send <instance> <operation-name> <arg>*)

is mostly a matter of which kind of syntactic sugar you prefer,
not a deep difference in how you think.  CLOS uses the function
call syntax in order to be more consistent with the rest of
Lisp.

Then, once you adopt the function call syntax, the generalization
to multi-methods seems fairly natural.  It does make it harder to
think of the objects as being in control, but is that enough to
make CLOS not be object-oriented?

Many people have tried to define the "essential" properties of object-
oriented programming.  I don't think there's anything wrong with trying
to do that, because it might further our understanding of OOP, but I
don't think it's very useful to be dogmatic about the results.  Not
only that, some people include as essential some things that don't seem
essential at all.

For example, I think T has an object-oriented component (see the
Adams and Rees paper in the last Lisp conference) even though it
doesn't have classes, uses generic functions instead of 'send',
and uses something more like delegation that inheritance.

As another example, I don't think C++ is not object-oriented even
though member functions are just functions.  That is, a C++ object
contains methods rather than acting as an interpreter for messages.

-- Jeff