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!