[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



    Date: Tue, 25 Sep 1990 14:14 EDT
    From: Jon L White <jonl@lucid.com>

    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:

Thanks.

    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?  You
shouldn't be able to use CHANGE-CLASS to change to a metaclass that uses
a totally incompatible representation, just as you can't use subclassing
to do that.  And if the metaclasses are compatible, maybe it isn't
really necessary to make the instances obsolete.  I don't really have a
strong opinion on what should happen here.

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

No opinion.

    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.

    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?

This is metaobject protocol business.

I looked at LISP-SYMBOL-REDEFINITION:MAR89-X3J13 version 8 and expected that
it would prohibit this entirely, but in fact it's silent on the point.  However,
in the absence of a metaobject protocol defining what it means, it's clearly
unsupportable for users to define methods on Lisp-supplied generic functions.
Maybe another issue covered this, or maybe it's a hole in the language waiting
to be filled by the metaobject protocol.

    I'm especially interested in  what Symbolics does for point 1.

I imagine the consequences are undefined.  I don't really know.