From: wsdng@... (=?ISO-8859-1?Q?Sascha_D=F6rdelmann?=)
Date: 2003-08-23T01:38:07+09:00
Subject: Re: Class variables - a surprising result

Mark Wilson <mwilson13@cox.net> wrote:
> It discusses Smalltalk's use of class variables and class instance  
> variables and provides examples of when one might wish to use them.  
> Caution is called for in using class variables with a class hierarchy,  
> because a change in the class variable in the superclass is changed for  
> all subclasses, so the value represented should be one that should  
> change in this way in the model.

Some notes one that.

VisualWorks used to call them class variables but they are now called
static variables because that's what people know from C++ or Java.
(The book seems to be about Smalltalk-80 which is the predecessor of
VisualWorks.)

I've never had any problems using them because the bytecode compiler
warns if you try to shadow a variable which is already defined in the
superclass. You couldn't do that with static variables in C++, either.

On the other hand: Smalltalk novices often have problems to understand
what class *instance* variables are for. I think it's better to leave
them to advanced programmers. Although they sometimes become useful -
in most cases you won't miss them. You could probably do several years
of Smalltalk programming without any knowledge about the underlying
meta-model with no harm.

> It also appears that Smalltalks 'pool dictionaries' have some  
> similarities to Ruby modules (although they seem more limited than Ruby  
> modules).

Sorry, but I don't see any parallels there. Pool dictionaries are a
means to store global or static data (and restrict access to them) but
usually not compiled methods. Compiled methods are part of some class
organisation structure and are only usable if associated to a class or
metaclass. I've seen hacks which replaced those associations
dynamically but you wouldn't call this type of programming "normal".

Cheers
Sascha