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