Re: change-class and class redefinition

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

        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!
I agree we need a term.  Ones I like slightly better are "external" and
"internal" instead of callable/not callable since clearly someone calls
these functions someplace.  It is just whether they are internal to the
implementation or not.

We already have the notion of specializable which means that methods may
be defined for a function that otherwise has none.  But is this a case
in which what is intended by non-speicalizable does not imply that there
are no methods -- only that "user" whoever that is, should not add any
more.  Under what circumstances does this make sense.  Why should
functions ever be unspecializable.  Only for implementation reasons I
feel (where assumptions have been bound into the code that is compiled).

    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 think initialization is more important (and I feel that we are
sufficiently close on change-class) that I would want to understand the
two together.  I feel it would be worth more to see your ideas on
initialization sooner.

     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?

I agree with this.  It is the assumption underlying the rule we proposed
for initialization that all initforms are run before further
initialization takes place. 

... A slot is a conceptual entity, not a word of computer storage
    at a particular address.  No slot contents are being copied or
    changed...  

I like this model.
  danny

ps Dave,
Did you see (and have a quick reaction) to the alternative
define-method-combination.
danny