Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!trwind!gumby!wiley!jay
From: jay@wiley.uucp (Jay Nelson)
Newsgroups: comp.lang.clos
Subject: Re: Is CLOS Object-Oriented ???
Keywords: CLOS
Message-ID: <27442A32.2814@wilbur.coyote.trw.com>
Date: 16 Nov 90 18:04:33 GMT
References: <1990Nov15.101847.26285@diku.dk> <3904@s3.ireq.hydro.qc.ca>
Sender: news@wilbur.coyote.trw.com (News Software)
Reply-To: jay@wiley.UUCP (Jay Nelson)
Distribution: comp
Organization: TRW Inc., Redondo Beach, CA
Lines: 33

In article <3904@s3.ireq.hydro.qc.ca> gamin@ireq-robot.hydro.qc.ca (Martin Boyer) writes:

>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.

We ran into an interesting problem the other day with CLOS.  We had
some code in Flavors that we were converting to CLOS.  We had two
classes: Class A contained information that should be updated and
Class B contained the name of the slot in Class A to change.  In
Flavors the code was:

  (setf (send class-b (send class-a slot-to-change)) new-value)

Under CLOS you need to say:

  (setf (#'(slot-to-change class-a) class-b) new-value)
         ^^^^^^^^^^^^^^
Which doesn't quite work.

The difference is that the protocol of "send" allows the message to be
derefenced, whereas CLOS doesn't.
Jay Nelson  (TRW)  jay@wilbur.coyote.trw.com