[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reinitialization
- To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Reinitialization
- From: kempf@Sun.COM
- Date: Tue, 12 Apr 88 14:52:35 -0700
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: Your message of Mon, 11 Apr 88 20:35:00 -0400. <19880412003504.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Couple responses/questions
> (a) initialize-slots-from-initargs instance &rest initialization-arguments
> (b) initialize-slots-from-initforms instance list-of-slots-to-consider
> (c) normalize-instance instance &rest initialization-arguments
I like this seperation, except I'm not sure what you have in mind
for normalize-instance?
>Another question is whether (a) and (b) should be
>generic, and if so whether they should dispatch on the instance or on
>the class.
Yes, I think they should. Example: a persistance metaclass which wanted
to initialize slots in a database. Certainly, this could be done in
bulk by specializing initialize, but the programmer might also want
it done in the other cases as well.
>(4) A subtle semantic change to class-changed and update-instance-structure
>has been proposed, specifically that unbound slots that are not new should
>be filled from their initforms instead of being left unbound. I'm opposed
I don't recall having seen the change, but I agree with your arguments
against it.
>One is that I'm opposed to making any
>changes in the first two chapters unless there is a good reason; I want
>that part of the CLOS spec to be over and done with.
This is also the best reason for keeping the four updating functions.
>(6) Why do the four updating functions have such inconsistent interfaces?
>It makes sense for two of them to take initialization arguments and the
I agree with your proposed changes, but, again, this would involve
changes in Chapters 1 & 2.
jak