Further to the :class :allocation fun!
(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
Chris
caw wrote:
> Further to the :class :allocation fun!
>
> (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.
You did not listen last time, maybe this time you will listen. [No, you
do not deserve a second chance, I am just a great guy.]
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
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Thanks Kenny,
> 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.
That's what I found surprising... that the class is not created anew
when the new class definition is compiled and loaded.
Thank you for the workaround.
caw <···········@gmail.com> wrote:
+---------------
| > 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.
|
| That's what I found surprising... that the class is not created anew
| when the new class definition is compiled and loaded.
+---------------
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
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Apr 20, 6:37 am, caw <···········@gmail.com> wrote:
> Thanks Kenny,
>
> > 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.
>
> That's what I found surprising... that the class is not created anew
> when the new class definition is compiled and loaded.
> Thank you for the workaround.
yes, object systems vary, and, in general, one could expect any number
of things to happen.
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
you will suffer fewer surprises.
caw wrote:
> Thanks Kenny,
>
>
>>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.
>
>
> That's what I found surprising... that the class is not created anew
> when the new class definition is compiled and loaded.
Ah, yes, I was starting to think that that might be the underlying
problem. In C, every edit/build/run cycle begins a brand new world from
scratch. With dynamic languages (not just Lisp), things stay around
unless explicitly whacked. In development we interact with a language
runtime to accretively erect an application. For example, deleting a
method from your source does not mean it no longer exists. One must seek
and destroy. Also, the language has support for things like gracefully
changing a class definition while instances of the class already exist.
Peek at AMOP and you will see that a class is an instance of a
metaclass, no different than any other class-instance relationship.
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
> Thank you for the workaround.
I'll throw in a Team Yobbo baseball cap.
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
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen