Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!ginosko!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.lang.lisp
Subject: Re: CLOS: is it OOP?
Message-ID: <1989Sep16.221107.22750@odi.com>
Date: 16 Sep 89 22:11:07 GMT
References: <19582@mimsy.UUCP> <29564@news.Think.COM> <11815@polya.Stanford.EDU>
Reply-To: dlw@odi.com
Distribution: usa
Organization: Object Design, Inc.
Lines: 57
In-reply-to: pallas@Neon.Stanford.EDU's message of 15 Sep 89 23:47:47 GMT

In article <11815@polya.Stanford.EDU> pallas@Neon.Stanford.EDU (Joe Pallas) writes:

   I'm inclined to agree that protection is not absolutely required for
   an object-oriented language (although I wouldn't want to use one
   without it).  But I would argue that it is precisely because of
   generic functions that CLOS CANNOT have protection.  To have
   protection, you must have a clearly defined protection boundary.
   Method invocations establish such a boundary, but generic functions do
   not.

Yes, there's some truth in this.  It's not the generic functions per
se that cause the problem though, since New Flavors has generic
functions, but does have a clearly defined protection boundary.  In
New Flavors, a method of a flavor can access instance variables
directly, and other functions cannot.  What causes the trouble for
CLOS is the addition of the multimethod concept, and all the changes
that it implies: there is no such thing as a "method of a class" in
CLOS, because one function might be involved with more than one class
at the same time.  I don't think this would have made it impossible to
put a protection boundary into CLOS, but it certainly would have made
it harder, and CLOS certainly can't be said to have one, given
get-slot.

   >The major benefit of generic functions is that it is like the rest of
   >Lisp.  You can pass them around wherever ordinary functions are
   >permitted.  For instance, they can be passed to mapping functions.  In
   >a message-sending system, programs that accept messages generally
   >don't accept functions and vice-versa; you end up writing
   >	#'(lambda (x) (send x 'foo))
   >alot.

   I can't say for sure, but I don't think this is true unless you spend
   a lot of time writing named helper functions in CommonLisp.  I just
   scanned through my Smalltalk sources and couldn't find any such
   trivial lambda expressions (blocks, in Smalltalk parlance).  You
   almost always want to do more than just send a simple message in such
   a case.  So you either have to write a special purpose method/generic
   function, or you use a lambda expression anyway.

The reason Smalltalk doesn't need these trivial things is that in
Smalltalk, all function calls have one uniform syntax, namely
Smalltalk message passing.  The problem with Old Flavors (which used
"send") is that the language now had two distinct syntaxes for
function calls: regular function calls, and "send".  The trivial
lambda expression is a way of converting one to the other, sort of
like a 120v-to-240v converter, inelegantly stuck in the middle of
things.  In New Flavors and CLOS, "send" is eliminated, and everything
uses the same syntax again, which gets rid of the need for silly
conversions.

In our experience, it was not really true that "You almost always want
to do more than just send a simple message"; we often ran into just
such cases.  For example, you might have an array of function objects,
and want to do (funcall (aref the-array n) arg1 arg2), and some of the
elements were implemented as methods on the class of arg1, but a few
were not.  It was a real pain in the neck.  We converted large bodies of
code to use New Flavors and always liked the results.