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

[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?


     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.



re: [redefinition prohibitions for various CLOS constructs ...]
    Maybe another issue covered this, or maybe it's a hole in the language 
    waiting to be filled by the metaobject protocol.

Probably the latter.  By now, it's become a crater.


-- JonL --