[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Making (CLASS-OF <class>) be EQ to <class>
- To: Jon L White <jonl@lucid.com>
- Subject: Making (CLASS-OF <class>) be EQ to <class>
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 27 Sep 1990 20:04-0400
- Cc: common-lisp-object-system@mcc.com
- In-reply-to: <9009251814.AA04061@caligula>
    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.