Path: 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 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: 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