Hi --

On Fri, 19 Oct 2007, Brian Adkins wrote:

> On Oct 18, 2:44 am, "Robert Klemme" <shortcut... / googlemail.com>
> wrote:
>> 2007/10/18, Brian Adkins <lojicdot... / gmail.com>:
>>> On Oct 17, 4:10 pm, Perry Smith <p... / easesoftware.com> wrote:
>>>> I am using this technique for class instance variables:
>>> Just out of curiosity, why do you want a "class instance variable"
>>> instead of a class variable?
>>
>> Probably because class variables have @@various issues as has
>> discusses before.  I would also recommend to not use them.
>
> What issues have you experienced with them to cause you to not
> recommend them? I rarely have a need for either class variables or
> "class instance variables", but I've yet to experience any problems
> with class variables.
>
> I think they have different purposes, strengths and weaknesses, but I
> wouldn't recommend not using class variables, so I'm curious if I'm
> missing some problem with them.

I'm on record as saying that class variables are the thing I dislike
most about Ruby, so I'll try to explain why.

They break encapsulation. They are visible to a weird assortment of
objects: class C, instances of C, class D < C, instances of D... all
the same variable. This cross-section of objects doesn't have anything
in common except that they can all see each other's class variables.

The prefix @@ makes it appear that they have some connection or
kinship with instance variables. Actually, they're almost the
opposite. Instance variables represent state on a strictly per-object
basis. Class variables cut across many different objects and scopes.
I would prefer them to look like $$this, since they're really a
kind of restricted global variable rather than an extended instance
variable.

The worst thing about them, in my view, is the amount of confusion
they have caused. The fact that there is something called a "class
variable" -- and that it looks vaguely like an instance variable --
has been a huge obstacle for people trying to get a grasp on the idea
that classes are objects and can, via *instance* variable, have their
own state. Class variables throw a big shadow over that otherwise very
consistent and lucid state of things. I've seen this happen again and
again for seven years.

In Ruby > 1.8, class variables are going to be somewhat more strictly
per-class. That's a mixed blessing. They're going to come closer to
representing a class's state, but then the question will arise: why
have both that *and* instance variables of classes? It's not
impossible to answer that, but it's not a bad question.

That sums up my views. Just so you know: I love Ruby madly :-) This is
one of the very few areas where I dissent strongly from the way it's
designed.


David

-- 
Upcoming training from Ruby Power and Light, LLC:
   * Intro to Ruby on Rails, Edison, NJ, October 23-26
   * Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!