Hi

I see your point but I partly disagree. As soon as you have singleton, 
and you want to teach
one inch of design you have to explain the difference.

For me classVariables are shared between a class and its metaclass 
(instances and their class)
and this point is more important that regarding inheritance because I 
refuse to access variables of superclasses directly.


(In fact
we did some experiences with the Prolog interpreter of Roel where we 
replaced all the direct access
by accessor calls and there was nearly no speed difference. So I would 
really like to see
direct instance variables disappearing (even if accessors could be 
optimized internally))


> "class variables" are things that belong to classes.
> "instance variables" are things that belong to instances.
> It doesn't get much clearer than that.


But this is not clear because from instance methods I can access 
classVariables which
when I teach that instances variables are all private is a violation of 
the rule. So classVariables are stuff that belongs to classes BUT 
SHARED among instances and classes.

and cannot access do not work with class variables. I'm not clear but 
I'm sure you see my point.


Stef


On mercredi, novembre 27, 2002, at 02:13  am, Richard A. O'Keefe wrote:

> Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> 	all this is something that I really appreciated in VW7.0 and I think
> 	that it would
> 	save a lot of energy to teachers and to newbies. I would loved to
> 	rename classVariables
> 	as sharedVariables (what they are in fact). This way we could say
> 	instanceVariables, class instance variable and shared variables.
> 	
> "shared variables" sounds like the things you find in PoolDictionaries.
> It's a very poor name because it fails to reveal what's the most 
> salient
> thing about these variables:  each class variable is owned by some 
> specific
> class and is visible within that class and its descendants.
>
> "class variables" are things that belong to classes.
> "instance variables" are things that belong to instances.
> It doesn't get much clearer than that.
>
> "class instance variables" are admittedly confusing,
> BUT they are also extremely rare.
> In the whole of Squeak 2.8 there were just four of them,
> in MorphicModel and Player.  In 3.2 one of those class instance
> variables has gone away.  There are now 13 classes with a total
> of 16 class instance variables:
>     CardPlayer		variableDocks
>     ExternalStructure	compiledSpec
>     Interpolateable	value
>     InterpreterPlugin	timeStamp
>     MorphicModel	prototype
>     ObjectMemory	timeStamp
>     PhonemeSet		arpabet
>     Player		scripts slotInfo
>     Player157		cardPlayer111 unscriptedPLayer1 unscriptedPlayer2
>     Player176		player157
>     TestResource	current
>     UnscriptedPlayer	ephemeralPlayerRef
>     VRMLClassNode	nodeSpec
> There are 1770 classes containing 5566 instance variables and 1288 
> class
> variables, so class instance variables are just 0.23% of the total 
> number
> of variables, and more than that, are concentrated in a handful of 
> classes
> that newbies are unlikely to be concerned with (at least until they are
> no longer newbies).
>
> It seems to me that teachers and newbies would save more time and 
> energy
> by simply ignoring class instance variables completely than they would 
> by
> changing the name of a core concept to be LESS meaningful and LESS 
> helpful.
>
>
>
Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes