[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reinitialization



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