harrisr@CS.RPI.EDU (Richard Harris) (05/02/91)
Is it possible to achieve something with an effect equivalent
to the following forms in a portable way with the MOP?
(defclass my-object (standard-object)
((file))
(:metaclass my-class))
(defclass my-class (standard-class my-object)
((my-class-info))
(:metaclass my-class))
The following excerpt from Chapter 6 seems to suggest that
what I want is impossible.
Since metaobject classes may not be redefined, no behavior is specified for
the result of calls to {\bf update-instance-for-redefined-class} on class
metaobjects. Since the class of class metaobjects may not be changed, no
behavior is specified for the result of calls to {\bf
update-instance-for-different-class} on class metaobjects.
----
Richard Harrisjonl%kuwait@LUCID.COM (Jon L White) (05/02/91)
re: [make a metaclass MY-CLASS that is its own metaclass]
The following excerpt from Chapter 6 seems to suggest that
what I want is impossible.
I hope it doesn't really make it "impossible", but simply leaves it as
unspecified.
The intent for Lucid's CLOS is to be able to do this, but after the 4.0
release went out, we discovered a glitch that prevented doing it in a
straightforward way. Thanks to Kim Barrett of Chestnut Software for
pointing this out last September; it is filed as bug report #05645
"RFE: want to be able to make circular CLASS-OF link", and with this
patched, your example is quite feasible. [see the "dribble" below.]
I say "feasible" rather than "straightforward", given all the constraints;
for example, note the need for doing the defmethod for VALIDATE-SUPERCLASS
at exactly the right point in time. [Of course, you could retract that
method at a later time if you wanted to; but you might need it if you are
expecting MY-OBJECT to serve as a kind of "maximal" class within the MY-CLASS
metaclas hierarchy. For other variations on this theme, see my email msg:
Date: Tue, 12 Feb 91 14:48:41 PST
From: Jon L White <jonl>
To: kanderso@BBN.COM
Cc: john@linus.mitre.org, barmar@think.com, commonloops@cis.ohio-state.edu
Subject: accessing clos objects
]
. . .
> (load "/pods/central/patches/bug-5645")
;;; Loading binary file "/pods/central/patches/bug-5645.sbin"
#P"/tmp_mnt/net/ss/patches/bug-5645.sbin"
> (setq mo (defclass my-object (standard-object) ((file))))
#<Standard-Class MY-OBJECT>
> (setq mc (defclass my-class (standard-class my-object) ((my-class-info))))
#<Standard-Class MY-CLASS>
> (defmethod clos-sys:validate-superclass ((x my-class) (Y standard-class)) t)
#<Standard-Method VALIDATE-SUPERCLASS (MY-CLASS STANDARD-CLASS)>
> (change-class mc mc)
#<My-Class MY-CLASS>
> (change-class mo mc)
#<My-Class MY-OBJECT>
> (describe mo)
Class Object:
Name: MY-OBJECT
MetaClass: MY-CLASS
Class-Precedence-List: (MY-OBJECT STANDARD-OBJECT T)
Direct-Superclasses: (STANDARD-OBJECT)
Direct-Subclasses: (MY-CLASS)
DirectSlots:
SlotName Allocation TypeSpec
FILE
> (describe mc)
Class Object:
Name: MY-CLASS
MetaClass: MY-CLASS
Class-Precedence-List: (MY-CLASS STANDARD-CLASS CLOS::SLOTTED-CLASS CLASS MY-OBJECT STANDARD-OBJECT T)
Direct-Superclasses: (STANDARD-CLASS MY-OBJECT)
Direct-Subclasses:
DirectSlots:
SlotName Allocation TypeSpec
MY-CLASS-INFO
InheritedSlots:
SlotName Allocation TypeSpec
FILE
CLOS::NAME
CLOS::DIRECT-SUPERCLASSES
CLOS::DIRECT-SUBCLASSES
CLOS::DIRECT-METHODS
CLOS::DIRECT-FORWARD-REFERENCED-SUPERCLASSES
CLOS::PRECEDENCE-LIST
CLOS::FULLY-DEFINED-P
CLOS::WRAPPER-AND-ISLOT-COUNT
CLOS::PLIST
CLOS::DIRECT-SLOTS
CLOS::SLOTS
CLOS::DEFAULT-INITARGS
CLOS-SYSTEM:SLOTD-INITARGS
>
-- JonL --Gregor@parc.xerox.com (Gregor Kiczales) (05/02/91)
Its great that the Lucid implementations supports this, and it would be great if other implementations did as well. But, the excerpt quoted by Richard Harris does, in fact, have the effect of not requiring implementations to support this. The reason for this restriction is that optimizations are easier if the implementor can be assured that the entire meta-level program has been defined before any of the base-level program is instantiated. This makes it possible to compute any optimizations at the time the base-level program is instantiated. Furthermore, since the meta-level program isn't permitted to change, it isn't necessary to be able to update those optimizations.
jonl%kuwait@LUCID.COM (Jon L White) (05/03/91)
Ah, Gregor's message made me think that I may have misread how much you wanted to be "possible"; indeed, he and I verbally confirmed that the new MOP book doesn't _require_ implementations to handle the CHANGE-CLASS case you brought up, but of course it doesn't _prohibit_ it either. On the other hand, we both hope that more implementations will actually do it, and then the portability question essentially becomes moot. -- JonL --