Making (CLASS-OF <class>) be EQ to <class>

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

    Date: Thu, 27 Sep 1990 20:52 EDT
    From: Jon L White <jonl@lucid.com>

    re:    1. When CHANGE-CLASS is applied to a class object, shouldn't it also 
	      call MAKE-INSTANCES-OBSOLETE on it?  [PCL mail from some time ago 
	      said yes.]
	Perhaps.  Doesn't it also need to check metaclass compatibility?  

    Hmmmmm, now that you mention it . . .   I guess checking VALIDATE-SUPERCLASS
    on the class-prototypes is ok?

I wouldn't know.

	 2. If there are methods defined on function FOO at classes respectively
	       <C1, C2 ...>, then how can one temporary override the effective 
	       method at that point, and cause it to defer to the next most
	       specific one?

	This is just CALL-NEXT-METHOD, so you must mean something that I didn't
	understand.

    I don't think CALL-NEXT-METHOD does exactly that.  For example, 
    CALL-NEXT-METHOD from within a single :AROUND method defined at the 
    point <C1, C2 ...>  will invoke (probably) the primary method defined
    at <C1, C2 ...>, rather than, say, the "effective" method defined for
    point <C1, T ...>.  

    I may have misunderstood the semantics of SEND-AS, but that what I expected 
    it to mean -- "Treat this argument, for purposes of message/generic-function 
    dispatch, as if it's type were explicity FOOBAR rather than it's real type."   
    Now, I fully agree with you that replaceing Method Combination by simply
    SEND-AS/LEXPR-SEND-AS is a loss; but an ocasional "exceptional" use of this 
    flavorized kludge might not be so bad.

    As my first note mentioned, one is very tempted to use :AROUND methods and
    CALL-NEXT-METHOD; but as Gregor indicated, CLOS just isn't one of "those"
    kinds of language that make explicit delegation like this easy.

I think I might understand what you're getting at now.

Here's how I react to this sort of thing:  The programmer has recognized that
a certain method provides some functionality that he would like to invoke, and
wants to have a name for that method and call it by its name.  Well, Lisp
already has a way to name pieces of functionality and allow them to be called
by name, and I don't think we need to add another one.  The invokable functionality
should have been made a function in its own right, and the body of the method
should have been a call to that function.  In the more general case where it 
was a set of methods that the programmer wanted to invoke, this functionality
should have been made a generic function in its own right, and the method for
one generic function should be a call to the other generic function.

The "problem" with what I say here is that the modularity has to be worked out
in advance.  I wouldn't allow people to reach inside an existing program and,
without changing the source code of that program, pull out some functionality
that they want, but which was not packaged into a function by the author of
that program.  Indeed, I wouldn't allow that.  Years ago I had some experience
with object systems that worked that way and my conclusion was that it was a
bad idea.  I think the author of the program has to decide what the modularity
is and what the protocols are, and the user of the program has to live with that
or else get the program changed "officially."