Re: change-class and class redefinition

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 21 Jan 87 13:32 PST
    From: Gregor.pa@Xerox.COM
    ....
    The most important comment I have is that I would like to have the
    default method on class-changed be responsible for copying over slots.
    I understand that the reason you put the responsibility for initializing
    the slots of the "new" instance and copying the slots in the same place
    (in change-class itself) is to prevent running the :initform of slots
    which already existed in the "old" instance.  Was this for efficiency or
    because you preferred those semantics?  

It's for semantics.  I believe it's important not to evaluate initforms
that aren't going to be used.  However, that isn't the only reason, or
even the most important reason, why I proposed it the way I did.  I want
the copying of the slots to be the responsibility of the implementation,
not of the programmer, for several reasons.  Some of these reasons
involve implementation-dependent issues that are beyond the scope of the
standard, but that doesn't make the reasons any less valid.  Here are
the reasons that apply to the Symbolics implementation.  I expect there
are additional reasons in certain other implementations:
(1) Reading an uninitialized slot of course signals an error, so
copying the contents of a slot has to check for that.
(2) When a new piece of storage has to be allocated, the moving of the
slot contents from the old piece of storage to the new piece and the
redirection of the instance to its new piece of storage have to be
an atomic operation.  Remember that the Symbolics implementation
is a multiple process implementation.
(3) Slots that contain special kinds of things, for instance logic
variables a la Prolog, may require special care to copy.
(4) I believe the current instance should be completely operable at
the time the class-changed methods are called, because the class-changed
methods may want to perform generic operations on the current instance,
as well as on the previous instance.  The instance can't be completely
operable if the slot values aren't there yet.

However, this is missing the major point.  I believe that "copying the
slots" is the wrong model of what is happening.  A slot is a conceptual
entity, not a word of computer storage at a particular address.  No slot
contents are being copied or changed.  Some slots are being deleted,
some other slots are being newly created and therefore initialized, and
the rest of the slots remain unchanged.  If a particular implementation
happens to work by moving the representation of a slot from location
1000 to location 1492, that's an implementation detail and not something
the programmer should see.  At the level of abstraction that programmers
should deal with, a slot is a slot and nothing is being copied.

    ....
    My reasoning, is that I think things are more complicated when the rules
    about when the various :initforms are run get complicated.  This is
    reflected in my initialization protocol which has the :initforms all
    being run all at once.

I don't think it's complicated.  The rule is that newly created slots are
initialized to the value of their :initform.  I'm assuming that the
:initforms for different slots are independent of each other and that
the language makes no commitment about the order in which :initforms
will be evaluated; are you assuming something different from that?
Differing assumptions might be the underlying reason why we're disagreeing.

If we can't finish change-class until we finish initialization I will go
back to working on initialization.  I've been working on that, in between
interruptions, but don't have anything to report yet.

    I like the name class-changed.  I also agree with DLW that we should
    invent a term for generic-functions which you are not supposed to call
    yourself.  We will need this term in the meta-object protocol chapter.

As an initial proposal, we could have "callable functions", "specializable
functions", and "functions that are both callable and specializable".  If
they aren't specializable it's none of your business whether or not they
are generic, which is why I said "functions" instead of "generic functions."
Specializable means you can define methods for them.  I don't claim this
is the best terminology in the world!

    The paragraph which says that previous has dynamic extent and also says
    it can be passed around needs to be re-worked.  What it says is exactly
    right, its just that its confusing.  It is very important to stress that
    previous has dynamic extent.

All of my English is pretty poor and will have to be gone over once we
have agreed on the facts.