[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change-class and class redefinition
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: change-class and class redefinition
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 22 Jan 87 14:54 PST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Thu, 22 Jan 87 00:57 EST
- Sender: 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
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
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
I like this model.
Did you see (and have a quick reaction) to the alternative