<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
That sounds like a good way for it to work.<br>
<br>
I'm not sure how safe it would be to depend on each<br>
of the extant implementation of Common Lisp to<br>
do this. It would probably be best if they all<br>
conformed; the only drawback would be the<br>
tiny possibility that some code somewhere is<br>
depending on the existing behavior. One could<br>
always use the old trick of having a compatibility<br>
mode for the sake of applications that want<br>
to move to the new release but whose developers<br>
don't have time to fix the application "the right way".<br>
<br>
-- Dan<br>
<br>
Pascal Costanza wrote:
<blockquote cite="mid:D5B3E43D-ABD3-4A5A-A65C-04BC61BC289F@p-cos.net"
type="cite">
<pre wrap="">On 6 Jan 2011, at 18:03, Didier Verna wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Daniel Weinreb wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This conversation has been good.
</pre>
</blockquote>
<pre wrap=""> Yup. Here's what I gather from it, mostly:
- a shared slot's initform is required to be evaluated when the class is
created,
</pre>
</blockquote>
<pre wrap=""><!---->
I agree here.
</pre>
<blockquote type="cite">
<pre wrap="">- however, nothing tells us that the resulting value is used immediately
to initialize the slot (it could just be stored somewhere), and
implementations seem to be free to do so right now, or later when the
first instance is created.
</pre>
</blockquote>
<pre wrap=""><!---->
I disagree here. I think the only valid time to initialize a shared slot is when the first instance of the class in question is initialized, using either an explicitly passed value via an :initarg or :default-initargs option, or using the most recently provided :initform. What the CLOS MOP says about class-prototype is not binding in this case, according to the HyperSpec the only way to initialize instances of user-defined classes is by way of initialize-instance, reinitialize-instance and/or shared-initialize. This usually happens implicitly as an effect of calling make-instance.
This effectively means the following:
- When a class is defined for the first time, the :initform for a shared slot needs to be evaluated immediately, and its result must be stored in some temporary memory location. (There is no notion of first-class dynamic environments in Common Lisp, so there is no other way of ensuring that the :initform can be evaluated in the correct dynamic environment.)
- When a class is redefined before the first instance of that class is initialized, the :initform for a shared slot needs to be reevaluated and the result stored in that temporary memory location, possibly overriding a previously stored result of an initform.
- When a class is redefined after the first instance of that class is initialized, the :initform for a shared slot can be ignored, because that shared slot is already initialized.
- When the first instance of a class is initialized, the shared slots can be initialized with the values stored in the temporary memory locations for the results of the initforms, which can in turn be discarded.
So, effectively, a shared slot behaves like defparameter before the first instance of a class is initialized, and like defvar afterwards. This is pretty insane. It would have been easier and more straightforward if there had been a :reinitialize slot option for shared slots which, if true, makes it behave like defparameter, and if false, makes it behave like defvar. That would have been unambiguous semantics.
There is no real advantage in having shared slots over global special variables. On top of that, the slot access protocols in the CLOS MOP also don't work that well in conjunction with shared slots. So it's better to avoid them. Fortunately, this is the only feature in CLOS that doesn't make any sense, as far as I can tell.
Pascal
</pre>
</blockquote>
</body>
</html>