On Thursday, August 21, 2003, at 11:41 PM, Ryan Pavlik wrote:

> <snip>
>>> I'd like to know if you are a designer, how would you design class
>>> variables in Ruby?  And how useful they are in daily usage?
>>> I'm just curious.
>>>
>>> 							matz.
>>
>> Interestingly, I find I never actually use class variables.  I don't  
>> know
>> why or why not.  I did in Java, but perhaps Ruby has simpler ways of
>> achieving the same things?
>
> I do regularly.  In many classes, I have a SQLIndex which helps me  
> query
> values across thousands or more objects quickly.  It works like this:
>
>     class MyClass
>       @_index = SQLIndex.new(...)
>     end
>
> I also have MyClass._index defined.  There was confusion on my part
> until I realized that @instance variables in a class were analogous to
> "class" or "static" members in Those Other Languages, whereas @@class
> variables were different.
>
> Basically, in Ruby, you _do_ have what C++/Java would call a "static
> class member", and you also have something else---@@class variables.
> It's mostly the term here that's confusing, I think.
> [snip]

Interesting reading can be found in the 'module4' pdf here:

http://wuarchive.wustl.edu/languages/smalltalk/Smalltalk/Squeak/docs/ 
BHoran/

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.

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

As a note, unrelated to the issue of class variables and class instance  
variables, I thought the book's initial discussion of inheritance  
(having Financial_history be a subclass of Spending_history) represents  
what would probably be a poor design decision, on many grounds.

Regards,

Mark