Initialization

[Dick Gabriel <RPG@SAIL.Stanford.EDU>]

I've reworked the material Sonya wrote to try to make the presentation
a little easier to understand. I hope that tomorrow I will be able to
put chapter 1 out on SAIL for Moon and Sonya to check for bugs. (It's
only Objection Creation and the updating/reinitialization sections, which
are now all together).

While reworking the material it occurred to me that there are some problems
with the naming of the generic functions.  I like the names
update-instance-for-redefined-class and update-instance-for-different-class.
I don't like the name initialize-instance for the generic function that does
what initialize-instance currently does.

What initialize-instance really does it to fill the slots of an instance
according to the initargs and the initforms that it is supplied. When
something is initialized, then it is either given a set of initial values
at the beginning of a program or it is restored to a fresh state. (This is
according to the Random House Second Edition, whose authors know about
computers). In our case we call this function on fresh instances, on munged
instances, and on instance we're altering to conform to different class
definitions. 

Furthermore, the generic function initialize-new-instance seems to me to
be the corresponding function to reinitialize-instance. Therefore, I
suggest we rename initialize-new-instance to be initialize-instance, and
we rename initialize-instance to be something like fill-and-initialize-slots.

Now, another possibility is to break up the current initialize-instance
into two pieces: one that fills slots using initargs and another that
fills unbound slots using initforms. Then we can name them fill-slots and
initialize-slots. We can pull the usual trick of stating that update...
and all those guys are implemented as if they called these two functions
but that optimizations are allowed (and method definitions would undo
those optimizations).

On the other hand, it's all pretty complicated already. 

			-rpg-