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

[Peter Benson <pab@lucid.com>]

   Date: Tue, 25 Sep 90 11:14:12 PDT
   From: Jon L White <jonl>

   Yea, there were numerous thorny issues connected to that one line of
   code -- (change-class my-std-class my-std-class).  Here's a high-order,
   three-line summary of each one:


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

Yes.  I think you and I had a discussion about this some time ago too.  As
I remember we decided this was true.

      Should this be as a :BEFORE method specialized to class CLASS?

I don't think that is necessary.  I suspect that users should be allowed to
define their own :BEFORE, :AFTER, and :AROUND for system supplied generic
functions.  I think the spec isn't exactly clear about that.  I think it
should say exactly what methods are defined for what generic functions s
the user will know if what she is doing is going to redefine a system
supplied method.  

   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?

I don't think there is any way to do this short of defining a new kind of
method combination.  It would seem there is no way to do this on a generic
function defined by someone else.  I don't there should be a way to do this
by default.  It seems to break modularity.

   3. Have we adequately enumerated in a single place the kinds of system
      definitions that user code can redefine without suffering  "undefined 
      consequences"; e.g., are SETF function names and methods covered?

Probably not.  The method signatures for the system defined methods are
listed on the function pages in Chapter 2.  Although not explicitly stated,
redefining primary methods with those qualifiers should clearly cause
'undefined' behavior.  It is not clear whether or not the user is allowed
to define :BEFORE, :AFTER, or :AROUND methods with the same specializers.  
This should be made explicit.  I don't care which way it is decided.

-ptr-