From: Rick DeNatale <rick.denatale@...>
Date: 2006-08-21T21:45:11+09:00
Subject: Re: Class variables in Ruby

On 8/19/06, Paul <prcorcoran@comcast.net> wrote:
> Hi Gary,
>
> I'm not quite sure what you mean by using "an instance variable of the
> class object". I am familiar with class variables and instance
> variables. In my case I wanted to cache the data in a class variable
> because *any* instance could reference the single class variable. Is
> there yet another type of variable (other than temporary method scope
> variables) that one could define?

Smalltalk has pretty much the same thing, there's a difference between
class variables which are shared by the class and it's subclasses, and
are traditionally implemented by binding an association between the
name and value into compiled methods, and class instance variables
which are instance variables of the class object, and are implemented
as instance variable slots in the class objects, so every subclass has
it's own value.  It's been awhile, and there are Smalltalk dialect
differences but these get declared in messages to the classes subclass
something like:

    Object subclass: #Foo ...
                instanceVariables: 'a b'
                classVariables: 'C1 C2'
                classInstanceVariables: 'ci1 ci2'

We also worked on a completely declarative model for class definition
in Smalltalk in X3J20, but I don't know if anyone picked it up.

In Ruby these are defined as they are encountered in execution and
marked with sigils, @ for instance and class variables, and @@ for
class variables, the difference between instance and class instance
variables being WHERE they are encountered.

In Smaltalk, class variables are in the scope of both class and
methods of the class which declares them, and its subclasses.
Instance variables are visible in methods of the class and it's
subclasses, and class instance variables to class methods of the class
and it's subclasses.  This the same as in Ruby.

Getting back to the original question about caching. It seems to me
that one of the differences between Ruby and Smalltalk in their
'traditional' settings which affects the use of patterns such as using
class variables as a cache is that the Smalltalk execution environment
is usually a long-lived object memory, sometimes even with
'reincarnation' if the image is saved, while the Ruby environment
usually gets set up, runs a while and then gets destroyed.  In a
server environment like rails, the lifecycle and even the number of
instances of the Ruby environment is configured during deployment, so
it's best if application code doesn't depend on a particular
lifecycle, or that application instances can communicate via classes
because they might not share the same class objects.

Smalltalkers who worked in transactional environments like MVS
Smalltalk running under CICS probably are more attuned to such
considerations.


-- 
Rick DeNatale
http://talklikeaduck.denhaven2.com