Re: Class instance variable idiom



Hi --

On Fri, 19 Oct 2007, Brian Adkins wrote:

On Oct 18, 2:44 am, "Robert Klemme" <shortcut...@xxxxxxxxxxxxxx>
wrote:
2007/10/18, Brian Adkins <lojicdot...@xxxxxxxxx>:
On Oct 17, 4:10 pm, Perry Smith <p...@xxxxxxxxxxxxxxxx> 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!

.



Relevant Pages

  • Re: Delegating class methods
    ... Every object has instance variables. ... are talking about alternatives to class variables. ... The main confusion with Ruby class variables comes from: ... It would be nice if there was a common term for 'instance variables ...
    (comp.lang.ruby)
  • Re: accessing class variables from the outside (beginner question)
    ... Where would you recommend using class variables over class level ...
    (comp.lang.ruby)
  • Re: Class instance variable idiom
    ... I'm on record as saying that class variables are the thing I dislike ... behave that is different from constants or singleton (note the ... I've never been completely comfortable with the Ruby ... Inheritance is a power tool, ...
    (comp.lang.ruby)
  • test/unit question. Accessing class variables?
    ... This is my first attempt in trying to use the ruby library test/ ... def test_parse ... uninitialized class variable @@whatisit in SimpleTest ... retreival of class variables from within the tests. ...
    (comp.lang.ruby)
  • Re: what is wrong with class variables? (newby)
    ... when there is a quasi-static condition to be transmitted to a hierarchy ... I've struggled with Ruby class variables myself. ... at them in the light of my Smalltalk experience. ...
    (comp.lang.ruby)