Re: change-class and class redefinition

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

    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
    more.

Right.

    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!

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

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.