🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.clos
Article #413

Re: accessing clos objects

#413
From: john
Date: Tue, 12 Feb 1991 17:06
46 lines
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!john

Show 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