Article View: comp.lang.clos
Article #479Re: Non-shared Class Allocated Slots
From: Gregor Kiczales
Date: Wed, 03 Apr 1991 20:59
Date: Wed, 03 Apr 1991 20:59
64 lines
3116 bytes
3116 bytes
In article <96B8613F4EBF600D38@cs.umass.EDU> CORK@cs.umass.edu ("Dan Corkill, COINS, UMass 413/545-0156") writes:
Neither the macro nor the meta-object approach to creating separate,
class allocated slots for each subclass is suitable when building
modular, layered systems using CLOS/PCL. For example, suppose I create
a class that is to be used (as a super) to created classes in other
systems/applications.
This is an instance of a general problem which can be phrased as: I need
a way for a superclass to affect the class of its subclasses without
going and editing all the defclass forms by hand. For example, I would
like to define the class TOP and have it and all of its subclasses be
instances of MY-CLASS without having to use the :metaclass option in the
subclass definitions.
(defclass top ()
()
(:metaclass my-class))
(defclass a (top) ()) ;this class should be an instance of my-class
(defclass b (a) ()) ;so should this one
There are two ways to do this using the metaobject protocol. (In each
case I am describing how to do it using the final version of the
metaobject protocol, if you are using early versions you may need to
tweak this a bit.)
1) If you can get a list of the names of all the subclasses, you can
``pre-define'' those classes with special forward-referenced classes
that, when the real definition comes along, don't go to STANDARD-CLASS
but instead go to MY-CLASS. That will get you the behavior you are
after I think.
A suitable method on ENSURE-CLASS-USING-CLASS, along with the advance
definitions and a subclass of FORWARD-REFERENCED-CLASS, should be all it
takes.
This technique has been used with success in various MOP-based block
compilers.
2) Another way of addressing the problem is to use VALIDATE-SUPERCLASS
to explicitly let superclasses participate in the selection of the class
of their subclasses. Something like the following works.
(defclass my-class (standard-class) ())
(defmethod validate-superclass ((sub standard-class)
(sup my-class))
(change-class sub my-class)
t)
(defmethod validate-superclass ((sub my-class)
(sup my-class))
t)
This needs to be a little more complex to handle forward references, but
the basic idea still applies.
Given either of these mechanisms, the problem of controlling the class
of subclasses can be solved and, given that, the :class-per-class
allocation you mention can be implemented.
Technical Details
Message-ID:
<GREGOR.91Apr3125953@tracer-bullet.parc.xerox.com>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!agate!bionet!parc!gregorReferences:
<96B8613F4EBF600D38@cs.umass.EDU>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!agate!bionet!parc!gregor From: gregor@parc.xerox.com (Gregor Kiczales) Newsgroups: comp.lang.clos Subject: Re: Non-shared Class Allocated Slots Message-ID: <GREGOR.91Apr3125953@tracer-bullet.parc.xerox.com> Date: 3 Apr 91 20:59:53 GMT References: <96B8613F4EBF600D38@cs.umass.EDU> Sender: news@parc.xerox.com Distribution: inet Organization: Xerox Palo Alto Research Center Lines: 64 In-Reply-To: CORK@cs.umass.edu's message of 3 Apr 91 19:21:00 GMT