[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> (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
>Another question is whether (a) and (b) should be
>generic, and if so whether they should dispatch on the instance or on
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
>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.