Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!unixhub!shelby!neon!phil
From: phil@Neon.Stanford.EDU (Phil Stubblefield)
Newsgroups: comp.lang.clos
Subject: Re: Is CLOS Object-Oriented ???
Message-ID: <1990Nov17.020531.16401@Neon.Stanford.EDU>
Date: 17 Nov 90 02:05:31 GMT
References: <3904@s3.ireq.hydro.qc.ca> <27443D49.2BE8@wilbur.coyote.trw.com> <PAB.90Nov16151057@3-mile-island.lucid.com>
Distribution: comp
Organization: Computer Science Department, Stanford University
Lines: 39

In article <PAB.90Nov16151057@3-mile-island.lucid.com> pab@lucid.com
 (Peter Benson) writes:
>
>In article <27443D49.2BE8@wilbur.coyote.trw.com> scott@wiley.uucp
> (Scott Simpson) writes (reformatted, edits bracketed):
>   I thought they [Flavors SEND and CLOS generic functions] were the
>   same too until someone at work came up with this problem in
>   Flavors:
>
>	   (setf (send self (send button :slot-to-change)) value)
>
>   What is happening is that (send button :slot-to-change) returns the
>   name of a slot to change and that slot is changed to VALUE on the
>   object SELF. How do you do this is CLOS?
>
>It's not a generic function doing it, but the designers of CLOS provided
>slot-value for occasions like this.
>
>(setf (slot-value self (slot-to-change button)) value)

I think that a better solution is to change the functionality of the
BUTTON as follows:

  (funcall (accessor-for-change button) value self)

The button now knows the name of the relevant accessor function rather
than the name of the slot.  This approach has two advantages:

  1) It uses the existing accessor, allowing full generic function
     dispatch, unlike the (SETF SLOT-VALUE) case.

  2) It provides better information hiding, insulating BUTTON from the
     implementation details of SELF.


-- 

Phil Stubblefield                                Email:  phil@rpal.com
Rockwell Palo Alto Laboratory                    Phone:  (415) 325-7165