(Lispworks)

(defclass foo ()
  ((foo :allocation :class
        :initform 'foo
        :accessor foo)))

CL-USER 1 > (setf f (make-instance 'foo))
#<FOO 216F620F>

CL-USER 2 > (foo f)
FOO

CL-USER 3 >

and when I use their nifty class browser, I'm told that class foo has
a slot:

Slot Name: FOO
Type: T
Initargs:
Initform: (quote foo)
readers: foo
writers: (setf foo)
allocation: :class

lovely...

I then edit the defintion of class foo:

(defclass foo ()
  ((foo :allocation :class
        :initform 'baz
        :accessor foo)))

making the initform 'baz.

recompile the form and :

CL-USER 3 > (setf f1 (make-instance 'foo))
#<FOO 2008FA6B>

CL-USER 4 > (foo f)
FOO

CL-USER 5 >

yep... this is the topic of the previous conversation...

but then when I look at class foo with the all-singing-all-dancing
class browser, I get told:

Slot Name: FOO
Type: T
Initargs:
Initform: (quote baz)  <-----**************
readers: foo
writers: (setf foo)
allocation: :class

And now I'm in a maze of twisty passages. The class has been modified,
according to the class browser, and initform has been evaluated,
storing the new value in the foo slot. But creation of a new instance,
and then calling the accessor on the new instance,  does not find this
new value...

I really don't understand this, and would be grateful for some help.

Cheers

Dude, initforms get tapped when new things get initted. In the case of a
class-allocated slot, the slot gets initted when the /class/ is created,
not the instance. Think about it. When the second instance gets created,
a new slot is /not/ being created. Duh. It is class-allocated. The
second instance gets the same slot as the first instance. There is no
reason to look at the initform.

ie, You simply have not grasped "class-allocated". Big word, I know.

The debugger is showing you that you have successfully changed the
class-allocated initform. Super. The next time you create /that class/
(NOT AN INSTANCE OF THAT CLASS!!!!), ie, when you exit your lisp and
re-enter and the Lisp runtime has to create anew /the class/, then you
will see the new initform take effect.

last time I also gave you the world's fastest workaround. hopefully you
ignored that as well and will spend the rest of your life changing
class-allocated intiforms by bouncing your Lisp.

Where should I send the tee-shirt?

kenny

ps. Is it OK if I just cut and paste when you ask the same question
tomorrow? k

--
http://www.theoryyalgebra.com/

"Algebra is the metaphysics of arithmetic." - John Ray

"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts

"Stand firm in your refusal to remain conscious during algebra."
    - Fran Lebowitz

Why is that "surprising"? The identity of a instance of a
class does not change when the class definition changes, right?
[Slots may be added or deleted or updated, but *identity*
doesn't change.]  Well, [by default] any class is itself
an instance of the class STANDARD-CLASS, so why would you
expect the identity of such an instance to change, either?

-Rob

Put it all together and you have classes finalized when the first
instance gets created. Then those instances and the class itself are
still there when you modify the class. So of course the class is not
being created anew, it is still the class of the existing instances. The
spec says the resulting, modified class must reflect the new definition,
and it does, as the debugger told you: the new initform is there. But
the slot in question is not being created when you make a new instance,
so the initform does not get consulted. And that is what we might want,
  to get the same old /class/ slot for our new instance. It might be
keeping vital information reflecting all that has happened since the
first instance was created. So -- the  punch line -- we want to modify a
class without losing the history of the class slot if there has been
any. If we want the class slot to get reinitialized, that is the same as
if we were not changing the class definition but for some reason decided
we wanted the class slot to get reset to some value -- we would have to
SETF it.

But the bigger point is: get used to surprises in re things staying
around between bulds. Think cumulative vs "fresh start". When you make a
change and the app does the same thing, do a find definitions to see if
methods you deleted from the source are still around. If you change a
DEFVAR initform and recompile do not think it then has the new value.
(But it would with DEFPARAMETER.) etc etc

kt

--
http://www.theoryyalgebra.com/

"Algebra is the metaphysics of arithmetic." - John Ray

"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts

"Stand firm in your refusal to remain conscious during algebra."
    - Fran Lebowitz

if you think this is confusing, go use rails in development mode.

if you would like to learn what to expect of lisp, look here,
  http://www.lispworks.com/documentation/HyperSpec/Body/m_defcla.htm
and, more particularly, on the consequences of redefining a class, as
referenced from there, here
  http://www.lispworks.com/documentation/HyperSpec/Body/04_cf.htm