Article View: comp.lang.clos
Article #413Re: accessing clos objects
From: john
Date: Tue, 12 Feb 1991 17:06
Date: Tue, 12 Feb 1991 17:06
46 lines
2524 bytes
2524 bytes
From: barmar@think.com (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Subject: Re: accessing clos objects
Message-Id: <1991Feb11.223240.20960@Think.COM>
References: <MIKEB.91Feb11101840@wdl35.wdl.loral.com>
To: commonloops@cis.ohio-state.edu
barmar@think.com (Barry Margolin) writes:
There is no automatic mechanism that keeps track of all the
instances of a class. You may implement such a mechanism for
classes you define, though. You can have a per-class slot (a slot
with the (:ALLOCATION :CLASS) option) that contains a list of all
its instances, and define a :BEFORE or :AFTER method on
MAKE-INSTANCE that adds the new instance to the list.
It's not clear how one would do this with :BEFORE and/or :AFTER
methods. An ordinary method specialized on the class in question
would never get called, since MAKE-INSTANCE gets called on symbols and
classes. So, presumably the idea is to define a method on
MAKE-INSTANCE that is EQL specialized to the class itself, or the name
of the class. But a :BEFORE or :AFTER method isn't going to be able
to get access to the new instance, only to the class. One would have
to use, for instance, an :AROUND or a primary method and use
CALL-NEXT-METHOD. Thus:
(DEFCLASS FLINTSTONE ()
((INSTANCES :ALLOCATION :CLASS
:INITFORM '()
:ACCESSOR FLINTSTONE-INSTANCES)
(NAME :ACCESSOR FLINTSTONE-NAME)))
(DEFMETHOD MAKE-INSTANCE ((F-CLASS (EQL (FIND-CLASS 'FLINTSTONE)))
&REST INITARGS)
(LET ((NEW-FLINTSTONE (CALL-NEXT-METHOD)))
(PUSH NEW-FLINTSTONE (FLINTSTONE-INSTANCES NEW-FLINTSTONE))
NEW-FLINTSTONE))
In general, I believe that EQL methods are fairly lousy with respect
to performance. Alternatively, on ecould define the recording
behavior on SHARED-INITIALIZE, or something like that. Defining a new
metaclass is probably a better solution, certainly aesthetically
speaking, although it makes it a little trickier to have the above
behavior be inherited.
John Burger
Technical Details
Message-ID:
<9102121706.AA06034@mingus.mitre.org>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!LINUS.MITRE.ORG!johnShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!LINUS.MITRE.ORG!john From: john@LINUS.MITRE.ORG Newsgroups: comp.lang.clos Subject: Re: accessing clos objects Message-ID: <9102121706.AA06034@mingus.mitre.org> Date: 12 Feb 91 17:06:30 GMT Sender: welch@tut.cis.ohio-state.edu Distribution: inet Organization: CommonLoops Lines: 46