[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Allocating Instances
- To: Andreas Paepcke <paepcke%hplap@hplabs.hp.com>
- Subject: Re: Allocating Instances
- From: David C. Martin <dcmartin%postgres.Berkeley.EDU@Berkeley.EDU>
- Date: Mon, 25 Jul 88 21:38:19 PDT
- Cc: CommonLoops.pa@Xerox.COM
- Email: dcmartin@postgres.Berkeley.EDU or {ihnp4,decvax}!ucbvax!dcmartin
- In-reply-to: Your message of Mon, 25 Jul 88 13:25:15 PDT <10410.585865515@hplap>
- Organization: University of California at Berkeley - Dept of EECS/CS Division
- Phone: 415/642-9585 (O)
- Redistributed: CommonLoops.pa
- Sender: dcmartin%avalon.Berkeley.EDU@Berkeley.EDU
I must fully agree w/ Andreas. In my implementation of the shared-object
hierarchy, much like Andreas' PCLOS, I made use of the ability of a metaclass
to define its own allocate-instance. Although use and ease are not rigorous
arguments, the fact that every object is an instance of some class leads me
to speculate that you must define a standard-instance just as you have
defined a standard-class in order to make the system pure.
I don't see how limiting the metaclass protocol to not allow definition
of the allocation of instance will do anything except render useless a major
portion of that protocol.
As for the previous letter about making an instance of a font and checking
to see if the font has already been made, the solution of using MAKE-FONT
and having the functions FIND-FONT and CACHE-FONT do the work does not allow
for a consistent function naming when creating an instance of a class.
I see two solutions to this problem: 1) create a new metaclass which caches
references to its instances based on some key in allocate instance and
(if possible) redefine the make-instance function to be a method so that you
can redefine the behaviour or redefine initialize to check for a cache-miss
(maybe a special?) and only do initialization on misses; or 2) make the
constructor function of a class accessible and use it in make-instance to
gain specialization.
dcm