🚀 go-pugleaf

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:
|>    I thought they 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)

Unfortunately, this is not an acceptable substitute in many situations.  Since
the setf method can have customized features (indeed, there does not even need
to be a slot defined to have a setf method) this hack won't work.

I agree that slot-value is a useful (if dangerous) feature, but it doesn't
take the place of the above case.  One bad (but functional) solution is:

	(eval `(setf (,(slot-to-change button) self) value))

Which forces run-time evaluation, but is semantically correct.  A simple macro
can hide this detail as follows:

	(defmacro setf-indirect (indirect object new-value)
             `(setf (,(eval indirect) ,object) ,new-value))

And this could be called as:

	(setf-indirect (slot-to-change button) self value)

I'm sure people could write this into nicer syntax, but this seems to be
the best approach to solving that problem for occasional use.  If
high-performance were an issue, I'd suggest storing a pointer to the
setf-method instead of the name of the slot.

Joe Konstan