From: John D. Burger
Subject: Re: CLOS: is it OOP?
Date: 
Message-ID: <71186@linus.UUCP>
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 suppose the author was referring to things like internal functions
and methods.  For example, one might define the SPECIAL-MULTIPLY
function to be internal to the COMPLEX-NUMBER class.  This guarantees
that SPECIAL-MULTIPLY may only be called within methods attached to
COMPLEX-NUMBER.

A problem with this, in particular, is that CLOS allows multiple
arguments of methods to be specialized.  Thus, it's not clear that it 
makes sense to think of methods as "attached" to classes.  I suppose
the metaphor could be extended for multi-methods, but I'm not sure if
it's worth it.  In any case, it's straight-forward to specialize
method classes and meta-classes in CLOS so as to have internal
functions and methods.  In particular, I imagine it could be done by
specializing the way applicable methods are computed.

As for other instances of protection and encapsulation, I think they
could be implemented as well.  That's the great thing about CLOS:
since CLOS is itself a CLOS program, you can beat the hell out of it
to get just about any sort of meta-level behavior.


-- 
John Burger                                               ····@mitre.org

"You ever think about .signature files? I mean, do we really need them?"
  - alt.andy.rooney
From: Jeff Dalton
Subject: Re: CLOS: is it OOP?
Date: 
Message-ID: <944@skye.ed.ac.uk>
In article <·····@linus.UUCP> ····@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