[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Assigning default slot value plus side effects?
- To: Marty Hall <firstname.lastname@example.org>
- Subject: Re: Assigning default slot value plus side effects?
- From: kanderso@DINO.BBN.COM
- Date: Fri, 13 Jul 90 14:50:47 -0400
- Cc: CommonLoops.PA@Xerox.COM
- In-reply-to: Your message of Fri, 13 Jul 90 09:41:10 -0400. <9007131341.AA18570@aplcen.apl.jhu.edu>
- Redistributed: CommonLoops.PA
Date: Fri, 13 Jul 90 09:41:10 EDT
From: Marty Hall <email@example.com>
X-Mailer: Mail User's Shell (6.1 4/26/88)
Subject: Re: Assigning default slot value plus side effects?
I had an application where, there were side effects that needed to occur
for all values in a certain slot of a class of objects. I noted that
it was obvious how to do this for changed values, by attaching a :after
method to (setf <accessor>) on the slot, but that I couldn't find a way
to make use of default values this way, because initialize-instance
uses slot-value (not the accessors) for putting values in slots.
Of course, I could write my own initialization function that initializes
the object then puts in the values using the accessors, but (being new
to clos), I wondered if I had overlooked something clean way of doing it.
Peter Saurugger responded that he didn't think there was any clean
approach, and went on to say:
> 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 ?
How does one "vote"? Also, does anyone know the motivation of X3J13 for
using slot-value instead of the accessors for initialization? Is there
a big efficiency win there?
I don't know what all the motivation is, but i can think of 2 reasons
for using SLOT-VALUE:
1. Not all slots have accessors, but every slot can be SLOT-VALUE'd.
2. It is certainly much faster to fill the slot, than it its to run
the SETF method. Since in most cases, the setf method simply fills
the slot every MAKE-INSTANCE would be needlessly slowed down.
I vote for using SLOT-VALUE and i'll do the extra work when i need to.
MAKE-INSTANCE is already slow enough.
The way i usually do this is to put an AFTER method on
INITIALIZE-INSTANCE that does the (SETF <ACCESSOR>). If you really
want this for every slot of every class you make, you can write your
own metaclass to do SHARED-INITIALIZE using (SETF <ACCESSOR>) for the
slots that have accessors.