From: Bulent Murtezaoglu
Subject: CLOS style q. class allocated slot initialization
Date: 
Message-ID: <878ylwr5pb.fsf@cubx.internal>
I have a bunch of classes with class allocated slots that get
initialized at runtime but before any instances are created.  I
initialize these slots by using files (or maybe eventually using other
data structures but it has to be at runtime as screen color-depth etc
needs to be known).  I can use [mop:] class-prototype (as suggested by
Kenny here not too long ago) that my implementation (LW) does support,
or provide an initform (maybe the filename itself for now) that I can
check for and do the right thing with in an after method for
initialize-instance.  Neither seems OK to me.  The first assumes MOP
for something that I think I ought to be able to do with pure ANSI CL,
the second is a horrible hack that entails storing single-use init
info and then abusing generic function flexibility to store something
entirely different in the same slot.  What elegant solution am I missing?

In code, (sorry for the typos, but should give you the gist)

;;option 1

(defclass foo (bar)
  ((problem-slot :allocation :class)))

(defun init-bars (barlist)
  (dolist (b barlist)
    (let ((c (find-class 'b)))
      (mop:finalize-inheritance c)
      (self (slot-value (mop:class-prototype c) 'problem-slot) (whatever c)))))

;;option 2

(defclass foo (bar)
  ((problem-slot :allocation :class :initform "foo-filename")))

(defmethod initialize-instance :after ((c bar) &key)
  (if (eq (type-of (slot-value 'problem-slot c)) 'string) ;; or subtypep, slot unboud etc
      (setf  (slot-value c 'problem-slot) (whatever2 c))))



thanks,

BM

From: Pascal Costanza
Subject: Re: CLOS style q. class allocated slot initialization
Date: 
Message-ID: <bqfjun$ola$1@f1node01.rhrz.uni-bonn.de>
Bulent Murtezaoglu wrote:

> I have a bunch of classes with class allocated slots that get
> initialized at runtime but before any instances are created.  I
> initialize these slots by using files (or maybe eventually using other
> data structures but it has to be at runtime as screen color-depth etc
> needs to be known).  I can use [mop:] class-prototype (as suggested by
> Kenny here not too long ago) that my implementation (LW) does support,
> or provide an initform (maybe the filename itself for now) that I can
> check for and do the right thing with in an after method for
> initialize-instance.  Neither seems OK to me.  The first assumes MOP
> for something that I think I ought to be able to do with pure ANSI CL,
> the second is a horrible hack that entails storing single-use init
> info and then abusing generic function flexibility to store something
> entirely different in the same slot.  What elegant solution am I missing?

I think that class-prototype is the right thing. You can easily 
implement it with allocate-instance as a workaround on platforms that 
don't support it.

(allocate-instance doesn't initialize an instance.)


Pascal

-- 
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Kenny Tilton
Subject: Re: CLOS style q. class allocated slot initialization
Date: 
Message-ID: <1eKyb.177050$Gq.21631514@twister.nyc.rr.com>
Bulent Murtezaoglu wrote:
> I have a bunch of classes with class allocated slots that get
> initialized at runtime but before any instances are created.  I
> initialize these slots by using files (or maybe eventually using other
> data structures but it has to be at runtime as screen color-depth etc
> needs to be known).  I can use [mop:] class-prototype (as suggested by
> Kenny here not too long ago) that my implementation (LW) does support,
> or provide an initform (maybe the filename itself for now) that I can
> check for and do the right thing with in an after method for
> initialize-instance.  Neither seems OK to me.  The first assumes MOP
> for something that I think I ought to be able to do with pure ANSI CL,
> the second is a horrible hack that entails storing single-use init
> info and then abusing generic function flexibility to store something
> entirely different in the same slot.  What elegant solution am I missing?

If you presume an absence of the MOP and take into consideration that 
the spec says a class does not have to be finalized until instantiated, 
it seems cleaner not to go near the class until the first instantiation, 
so I like playing with initialize-instance, because that seems like the 
best legal hook available.

This can be made a little neater if you create a class-allocated slot 
called class-inited-by-app-p and initialize to nil, then re-use that for 
any class with a slot or slots needing such attention. That way you are 
not putting bogus things in a slot to serve double-duty as a flag, you 
can manage multiple class slots for one class off the one inited flag, 
and it all comes out better self-documented.

But that's all just off the top of my head; I have not mucked much with 
class slots to be able to speak from experience.

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application