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

[barmar@Think.COM (Barry Margolin)]

    Date: Wed, 13 Mar 91 09:13 CST
    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).  That is, simple re-evaluation of the class definition
    with a different :INITFORM does not alter the slot's value.  Only if I
    remove the slot (or change its allocation mode), then put it back again,
    is the slot reinitialized.  My understanding of the CLOS spec is that
    this is indeed the required behavior.  But isn't there any way to get
    the behavior 1I0 want (modification of the slot's value when redefined
    with a different :INITFORM)?  Or is this simply the wrong application of
    :ALLOCATION :CLASS?

First, your message would be more appropriate to common-lisp@mcc.com or
the CLOS-specific mailing list, unless you're looking for
implementation-specific ways to get around your problem.

If you're using :ALLOCATION :CLASS to replace a DEFVAR, then you are
using it appropriately.  The value isn't "frozen forever", the slot is
expected to be updated as a matter of course; the only difference
between :CLASS and :INSTANCE allocation is that all the instances share
the same slot.  It wouldn't be appropriate to replace a DEFPARAMETER or
DEFCONSTANT with :ALLOCATION :CLASS.

It wouldn't be appropriate for the class slot to be reinitialized
automatically when the class is redefined.  The fact that you are
redefining the class doesn't necessarily mean that you want to revert
everything.  If the class slot contains state, it shouldn't be thrown
away automatically.  If you want the slot reinitialized, you can easily
write a form that updates it.  If CLOS were to reinitialize them
automatically, it would be harder for users who don't want the behavior
to stop it.

Your message suggests that you think reinitialization should only be
done when the class has been redefined with a "different :INITFORM".
Different in what way?  If the form is a list, it will almost certainly
be non-EQ to the previous one.  Non-EQUAL is probably what you mean, but
just because the form isn't EQUAL doesn't mean you really want it
re-executed.  For instance, you may have renamed a function, and changed
the init form as part of fixing up the callers.

    Note that Common Lisp specifies for DEFVAR the same style of behavior.
    That is, re-evaluation of a DEFVAR with a new initializer is not
    supposed to modify the variable's value, but Symbolics' implementation
    does so anyway (and thankfully so, in my opinion), albeit with a
    warning.

Genera doesn't normally reinitialize DEFVARs, either.  There are special
cases made when you evaluate a DEFVAR with c-sh-E or c-sh-C in the
editor, or put the DEFVAR in a patch file, on the assumption that you
hit c-sh-E or m-X Add Patch on purpose.  I've more than once been
screwed by these special cases.  I can live with the c-sh-C special
case, but the patch file hack is bogus.

                                                barmar