[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on current state of Initialization.
- To: email@example.com
- Subject: Comments on current state of Initialization.
- From: Jon L White <firstname.lastname@example.org>
- Date: Sat, 21 May 88 06:44:29 PDT
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
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
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 --