[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change-class and class redefinition
- To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- Subject: Re: change-class and class redefinition
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 22 Jan 87 18:58 EST
- In-reply-to: <870122-145237-1241@Xerox>
Date: 22 Jan 87 14:54 PST
From: 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.
The reason I don't like "external" and "internal" is that these seem to
refer to the visibility of the name. An "internal" function that is
"specializable" by someone on the outside seems like a contradiction to
me. In other words, nothing obviously says that "external" and "internal"
refer to the calling side rather than the specializing side.
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
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).
Then "specializable" means "this standard says you are supposed to
specialize this function as part of your normal programming", which is not
the same as the negation of "it is impossible to specialize this function."
I can see this is going to be hard to explain in a document, because there
are all these subtle distinctions.
To take examples from the current draft proposal, print-object is
specializable and not callable, while make-method is callable, not
specializable, and not generic, and get-method is callable, generic,
and not specializable at the outer layer of the standard, but
may be specializable (for some reason that isn't obvious to me)
at the meta-object layer of the standard. I don't know whether these
examples make it clearer or more obscure!
Did you see (and have a quick reaction) to the alternative
I gave it a quick read but I'm not working on method combination this
month. It's too easy to use up all the time polishing the last details
of one issue to the total neglect of other equally important issues.