Re: Assigning default slot value plus side effects?

["Peter N. Saurugger" <peter-s@molbio.cbs.umn.edu>]

> I'm new to CLOS, so excuse me if this is a basic question.

I'm not quite new, but ran into the same problem (and have not found
any *elegant* way to circumvent the problem: usually I write the slot 
values after initializing the instance, as you suggested)

> 
> (defclass foo () ((bar :accessor bar)) )
> 
>    (defmethod (setf bar) :after (bar-value (object foo))
>       (format t "~%Put the value ~S into bar slot of ~S." bar-value object))
> 
> My problem is with a default value for the slot. I want to assign a default
> value, but still have my after method fire. Ie I added a :initform to
> the bar slot of foo objects. However, initialize-instance
> uses setf on slot-value, rather than using the accessor, so my :after
> method does not fire when I make an instance of foo.
> 

Short of rewriting shared-initialize (I guess in init.cl) to use accessors
(if available) instead of slot-value ... - you could use the following (and
ugly) kludge:

	(defmethod initialize-instance :after ((object foo))
	   (setf (bar object) (bar object)) )

You have to specify this for every object-slot combination
you want to show this behaviour. Of course, you could specialize it on
any instance of standard-class, and update all the slots of this object
the way it is shown above for a single slot.

While the X3JI3 Specs mention the possibility of adding to the existing
initialization-protocol, the behaviour you describe does not seem to be
mentioned in this document.

I agree very strongly with you that on initialization I would expect the
same behaviour as when updating a slot. I do not know whether these specs 
still can be amended, but if there is no major reason against this, why 
not "vote" on the possibility of an amendment to the behaviour of 
shared-initialize ?


Peter N. Saurugger, Director		peter-s@molbio.cbs.umn.edu
Molecular Biology Computing Center
Coll.Biol.Sci., UofMN