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.