Comments on current state of Initialization.

[Jon L White <edsel!jonl@labrea.stanford.edu>]

Why should there still  be three initialization protocls: "shared-initialize",
"initialize-instance",  and "reinitialize-instance" (sp?).  

Why not just "initialize-instance" with a keyword argument for whether or 
not it is a first-time initialization?  In each case, the specialization
needed is over the instance, and not over the slots-for-initforms argument,
or the initargs argument, or any other arugment.  And so _most_ of the 
processing will be the same regardless of whether the caller is make-instance
or one of the update-instance-for-<munged>-class functions (i.e., whether 
initializing afresh or whether re-initializing).  In fact, for many classes 
I would guess that the particular list given as the 'slots-for-initforms' 
argument would adequately cover any necessary distinctions between fresh 
allocation and "update-instance-for-<munged>-class".  Direct user calls, if
any, could pass this keyword argument, rather than decide between two 
differently named functions.

I presume that the main primary method is the one whose chief purpose is to
set slots, first from the initargs and then from the initforms, and that this
wouldn't need to be modified by the user.  [In fact, letting the user change
this primary method is probably a mistake.]  Again, I would guess that most
user :after methods wouln't be concerned with the distinction between
"fixing up" the initialization of a fresh instance, and that of "fixing up"
the re-setting of slots on an "old" instance; in each case, the more 
important information is in the 'slots-for-initforms' argument.


In short, what I fail to see is any justification for hairing up the
protocol to inject a generic function that seems to have no particular
user benefit: reinitialize-instance.  Looking over back mail, I find
this one comment from Danny:

    Date: 8 Apr 88 15:37 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>
    Subject: Re: (re)initialization revisited 
    In-Reply-To: kempf@Sun.COM's message of Thu, 07 Apr 88 12:13:45 -0700
    To: kempf@Sun.COM
    Cc: common-lisp-object-system@SAIL.STANFORD.EDU

    Jim proposes removing some functions in the spec.  I sympathize with this 
    as a general goal.  But in this case I think it is misguided.  There are 
    really four concepts
    1) initializate (make a brand new instance have the right state)
    2) reinitialize (make an old instance have a "standard" starting state)
    3) class-changed (make a change from one form of current instance to another)
    4) update-instance-structure (make an appropriate current instance from an
    outdated instance.

    Because there are four concepts, there must be four entries so that users 
    can change what is done for each.  Collapsing concepts into a commonly 
    named fn just causes confusion.

    . . . 

    Reinititializing must potentially take into account old values on slots.
    Initialization never has to.  We introduced the general concept because we
    had two examples in CLOS itself that require it: instances of 
    standard-class, and instances of standard-generic-function.  Both must 
    take into account previous state of the objects to be changed.

But still, this is not justification for imposing a complexity that
will almost never be used by the end user, and for which there is an
adequate alternative: keyword argument to initialize-instance.  Note
that there is no need to split off re-initialization due to a difference
in the ways in which it might be specialized.


-- JonL --