[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Changing the :INITFORM of a slot with :ALLOCATION :CLASS

    Date: Fri, 15 Mar 1991 17:52-0500
    From: ACW@yukon.scrc.symbolics.com (Allan C. Wechsler)

	Date: Wed, 13 Mar 1991 10:13 EST
	From: lgm@iexist.att.com

	My CLOS classes often have associated with them various parameters which
	are not per-instance but merely per-class.  In Flavors I simply used
	DEFVAR or DEFPARAMETER to define such a variable or parameter, but with
	CLOS I would prefer to tie the variable/parameter more tightly to its
	class by defining it as a slot with :ALLOCATION :CLASS.  My difficulty
	is that once such a slot has been defined and initialized via :INITFORM,
	the slot's value is frozen forever (unless explicitly modified via an
	ad-hoc SETF).

    My feeling has been that shared slots are not an appropriate place to
    store information about a class.  Slots in general are for attributes of
    instances.  If it happens that all the instances of a class have the
    same value associated with that attribute, then a shared slot is
    appropriate.  An example is the weight of some part in a mechanical CAD
    program.  All parts of a particular kind have the same weight, but the
    weight is not a property of the class; it is a property of the part.

    All this just makes your real question more pressing: what is the right
    implementation for properties of a class?

    I keep hoping that X3J13 will accept enough of the meta-object protocol
    to allow this to work:

    (defclass counting-class (standard-class)
       ((number-of-instances :initform 0 :accessor number-of-instances)))

    (defmethod make-instance :after ((class counting-class) &key)
       (incf (number-of-instances class)))

This seems all right for something which is obviously a property of the
class, but there seems to me to be another kind of property, namely a
property of all members of the class.  For this, a class-allocated slot is
the right thing if the value isn't going to change or if you will change
it via the SETF mechanism as outlined in the original message on the
subject.  However, another way to go with this is to have a method which
returns the value you want for members of the class:

  (defmethod color ((thing elephant))

Note that by changing this definition and recompiling, you get the result
you want, namely that COLOR on any member of the class will return the new
value.  This is unlikely to be slower than accessing a class-allocated
slot in any CLOS, by the way.