This conversation has been good. I agree with both Svante
and Scott.

As is often the case with the spec, it is not quite unambiguous.
It seems to me that the spec is having trouble deciding whether
it is a real, strict, firm language spec, or a useful tutorial/reference
documentation aimed at what programmers care about
the most. Both are worthy things to do but they can be
at odds with each other in some cases. For class slots,
I think some parts of the spec may have been written
without class slots in mind, forcing all of us to be
"language lawyers", infering things from fragments.

The Java Language Spec is like the first one, and when
it comes to this topic it is utterly specific. (That's
what happens when Guy Steele writes a spec;
yes, I am a GLS fanboy...)

Shared slots are based on a venerable idea,
from Smalltalk-80. But that language didn't
have any other kind of variable besides
slots of instances!

If you have class c1 with shared slots cs1 and cs2,
why not just have two global variables (e.f. defvar)
called *cs1* and *cs2* sitting next to the defclass?

At least one reason, and maybe the only reason,
is that the initial value is figured out in a way
that may depend on class precedence.

Whether that justifies the added complexity
of having the feature is hard to prove one
way or the other; it's a matter of opinion.
I don't think I've ever used class slots.

-- Dan

Martin Simmons wrote:


Overall, I think shared slots are a bad idea.  As discussed in a previous
topic, defclass by itself doesn't provide very good encapsulation.

Another gotcha is that reevaluating a defclass with a different value for the
initform doesn't reinitialize the slot.