Re: (re)initialization revisited

[kempf@Sun.COM]

I agree in principle with Gregor's initial message, but all the proposed
alternatives so far leave me less than enthusiastic. The proposed
solutions have involved using flags, function valued arguments, or
special variables to pass a function to four different generic
functions which ultimately end up doing the same thing. I'm going to argue
for a solution which I proposed briefly last fall, namely collapsing
the initialization functions into one or two.

In particular, note the following:

1) Neither update-instance-structure nor class-changed is meant to be
called by the programmer. This means that their interfaces could be
rearranged to be the same, by either bundling the added-slots,
discarded-slots and property list arguments to update-instance-structure 
and simply passing the old object, or  by unbundling
the previous object instance to class-changed and passing that information
in the form update-instance-structure currently gets it. The kernel code which
calls the merged function would take care of formatting the call correctly.
This would allow one of the two functions to be dropped.

2) This leaves initialize-instance and reinitialize-instance. Since
these interfaces are the same anyway, what's the point of having two
differently named functions? Chapter 3 implies that the only difference
is that reinitialize-instance takes care of calling update-dependents,
but this seems to have been dropped in the current discussion. Even
if it hadn't been, update-dependents could be called upon initialization
also, with, of course, no result since no dependents have been registered
on object's state yet.


This leaves us with two functions:

1) A reinitialization function, which gets passed an assortment of information
on the old object in some form and the new object, allowing the user
to customize what precisely the initialization arguments are.

2) A raw initialization function, which gets passed the initargs.

Since 1) basically needs to call 2), I'd suggest that 1) be named
reinitialize-instance, and that 2) be named initialize-instance.

There are plenty of refinements one could think of, like how to
allow the kind of pairwise generic dispatch which 
class-changed currently allows, and details to fill in, but
rather than take the time to hack out some code, I'd like to
see what people think of this idea.

The problem with the other solutions proposed so far is that they
end up adding yet another function to CLOS, when some judicious
subtraction and rearrangement might reduce the bulk somewhat and
also provide a more unified solution.

		jak