Stephane Ducasse ducasse@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.
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@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@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
"Richard A. O'Keefe" ok@cs.otago.ac.nz wrote:
Stephane Ducasse ducasse@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.
Incidentally, a class variable and a pool variable (or whatever you call the things in pool dictionaries) are extremely similar. Their only difference is with which methods can access them. Likewise for global variables: it's the same thing, only visible everywhere.
This similarity is so strong that it even appears in the implementation of these things: all three kinds of pools of variables are stored as dictionaries.
Anyway, I'll second that students get confused over this difference. However, I'd like to point out that almost no beginner programs need class variables at all, and thus they can be left out for a long time. In fact, you may decide even to just use global valiables -- after all, class variables have just shy of the bad design problems that global variables do. It's too bad that class methods aren't quite as easy to do without, because those confuse people too; but maybe there, as well, people could use a "Foo new initialize" style and thus avoid class methods for a long time.
Lex
On Fri, 6 Dec 2002, Lex Spoon wrote:
Incidentally, a class variable and a pool variable (or whatever you call the things in pool dictionaries) are extremely similar. Their only difference is with which methods can access them. Likewise for global variables: it's the same thing, only visible everywhere.
Don't forget Metaclass instance variables too, which are shared... except that they aren't. ;)
Ian
squeak-dev@lists.squeakfoundation.org