Class Level Variables

ruby-talk
21

OK, I now understand the difference.

Probably I'm too new to programming to understand the full power of class
variables, and I found this concept a little bit dangerous because you can
affect the whole behavior of a class by simply changing a class variable in
any other subclass ... so I try not to use class variables for noiw.

I still need to read more and more :smiley:

Thanks Gary

···

El Lunes, 30 de Abril de 2007 19:15, Gary Wright escribió:

On Apr 30, 2007, at 1:52 PM, German Monfort wrote:
>> 2) Class variables are associated with a class *and* its subclasses
>> and the order of initialization is important.
>>
>> class C
>> @@foo = 42 # shared by C and its decendents!
>> def foo
>> @@foo # shared with C, D, and E
>> end
>> def bar
>> @@bar # this is C's @@bar
>> end
>> end
>>
>> class D < C
>> end
>>
>> class E < C
>> @@foo = 43 # @@foo shared with C, D, and E
>> @@bar = 44 # @@bar only defined for E
>> def bar
>> @@bar # this is E's @@bar
>> end
>> end
>>
>> puts D.new.foo # 43
>>
>> puts E.new.bar # 44
>> puts C.new.bar # undefined!
>>
>> class C
>> @@bar = 45
>> end
>>
>> puts C.new.bar # 45
>> puts E.new.bar # still 44
>>
>> Gary Wright
>
> Shouldn't be
> puts D.new.foo # 42 ?
>
> Because D < C and has no foo method defined (so it uses C' foo) and
> also has
> no @@foo defined (so it uses C's @@foo) which is set to 42 not 43.
> I'm confused here.

I was illustrating the fact that C and E don't share the same @@bar
due to
initialization order and the location of the definitions of C.bar and
E.bar.

If you called D.new.foo you would get 43 because @@foo is shared by
C, D, and E
and was updated to reference 43 in the class block that defined E.

If you called D.new.bar you would get 45 because the call to 'bar'
would be
implemented by the definition in C where @@bar refers to C's @@bar.
This is
a good example of how class variables are not relative to self!

Gary Wright

22

> Don't use @@foo, ever. ___Unless you know *why* you want to___. They add

emp added

Could not agree more with you, however, I would not dare stating this
as a *General Rule of Conduct*.
Will @@class_iv go away? I do not think so.

I agree with you that it can't be just a rule. Ruby 1.9 fixes some
issues with them though, so it'll be less scary there...

I'm still waiting for the killer use case that justifies them...

···

On 4/30/07, Robert Dober <robert.dober@gmail.com> wrote:

On 4/30/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:

23

Well Ruby's class variables are unusual in their semantics, even veteran
programmers get confused by them.

The usual recommendation is to use 'class instance variables' when you
want to have state associated with a particular class object (vs. a
class hierarchy.) The easiest way to do that is to create attributes
via the singleton class:

class A
   class <<self
     attr_accessor :alpha
   end
end

class B < A
end

A.alpha = 4
puts A.alpha # 4

puts B.alpha # nil
B.alpha = 5
puts B.alpha # 5

puts A.alpha # 4

In this way you define the accessor once but the state is unique to each
class and to each subclass.

Gary Wright

···

On Apr 30, 2007, at 9:32 PM, German Monfort wrote:

OK, I now understand the difference.

Probably I'm too new to programming to understand the full power of class
variables, and I found this concept a little bit dangerous because you can
affect the whole behavior of a class by simply changing a class variable in
any other subclass ... so I try not to use class variables for noiw.