Forum: Ruby Class Variable Confusion

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-12-21 22:05
(Received via mailing list)
I generally avoid class variables but at the last meeting of the New
Haven Ruby Brigade a simple question about them led to a long
discussion and irb session that only served to confuse us all more.

I'm hoping someone on the list can shed some light on a couple of
issues that were raised:

 >> class A
 >> @@avar = 'hello'
 >> end
=> "hello"
 >> A.class_variables
=> ["@@avar"]
 >> A.class_eval { puts @@avar }
NameError: uninitialized class variable @@avar in Object
         from (irb):5
         from (irb):5
 >> class A
 >> puts @@avar
 >> end
hello
=> nil
 >> class A
 >> def get_avar
 >> @@avar
 >> end
 >> end
=> nil
 >> a = A.new
=> #<A:0x4ba360>
 >> a.get_avar
=> "hello"
 >>   a.instance_eval { puts @@avar }
NameError: uninitialized class variable @@avar in Object
         from (irb):16
         from (irb):16
 >>


It seems like a block evaluated by class_eval should have access to
the class variables. Similarly, it seems like if an instance method
(get_avar in the example) has access to the class variable then the
variable should also be visible via instance_eval.

In both examples above (class_eval and instance_eval) it seems like
the class variable @@avar is being looked up relative to the
top_level object and not relative to the class and instance objects
respectively.


What am I missing?

Gary Wright
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-12-21 22:45
(Received via mailing list)
Hi --

On Fri, 22 Dec 2006, gwtmp01@mac.com wrote:

> => "hello"
> => nil
>>>   a.instance_eval { puts @@avar }
>
> In both examples above (class_eval and instance_eval) it seems like  the
> class variable @@avar is being looked up relative to the  top_level object
> and not relative to the class and instance objects  respectively.
>
>
> What am I missing?

You had me at "I generally avoid class variables" :-)

Here's another one you'll like:

   @@avar = 1
   class A
     @@avar = "hello"
   end
   puts @@avar  # => hello

   A.class_eval { puts @@avar }  # => hello

I love Ruby madly, but (or "therefore"? :-) I would be happy never to
see another class variable again.  The confusingness-to-usefulness
ratio is extremely high.


David
Ec8b2eff714fad2cf82d89d2d6a66021?d=identicon&s=25 Chunyun Zhao (czhao)
on 2006-12-21 22:59
(Received via mailing list)
Seems it works perfectly fine when evaluating the string instead of
block:

  class A
    @@avar = "hello"
  end

  A.class_eval("puts @@avar")  # => hello
  A.class_eval { puts @@avar } #=> throws NameError

Very interestsing, anyone could explain it?
8b66530927e39b74a7ecc079e0d7a734?d=identicon&s=25 David Goodlad (Guest)
on 2006-12-21 23:03
(Received via mailing list)
On 12/21/06, Chunyun Zhao <chunyun.zhao@gmail.com> wrote:
> Seems it works perfectly fine when evaluating the string instead of block:
>
>   class A
>     @@avar = "hello"
>   end
>
>   A.class_eval("puts @@avar")  # => hello
>   A.class_eval { puts @@avar } #=> throws NameError
>
> Very interestsing, anyone could explain it?

Since the block acts as a closure, the class variable references seem
to be bound to its original scope; iirc, the only variable types that
will change scope in the context of a class_eval (which changes the
value of 'self') are instance variables.  That's why the string will
evaluate correctly, while the block fails to find the class variable.

I'm not an expert, but this has been my experience.

Dave
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-12-22 01:10
(Received via mailing list)
On Dec 21, 2006, at 4:44 PM, dblack@wobblini.net wrote:
> Here's another one you'll like:
>
>   @@avar = 1
>   class A
>     @@avar = "hello"
>   end
>   puts @@avar  # => hello
>
>   A.class_eval { puts @@avar }  # => hello

Let's see if I understand what is going on:

When @@var is set to 1 at the top-level it is associated with the
class Object (a feature of the top-level context) and as such @@var
then becomes visible to the entire class hierarchy rooted at Object
(i.e., all objects).  When @@avar is evaluated in the class A block,
Ruby finds @@var already defined for the hierarchy (because A is a
subclass of Object).  So in this example all three occurrences of
@@avar are associated with the same class variable.  If you reverse
the assignments:

   class A
     @@avar = "hello"
   end
   @@avar = 1

   A.class_eval { puts @@avar }  # => 1
   class A
     puts @@avar		      # => hello
   end

There are now two distinct class variables named @@avar, one is
associated with Object and another is associated with class A and
shadows the one associated with Object.

I still don't understand why class_eval/instance_eval don't affect
the resolution of class variables in a manner analogous to how they
affect the resolution of instance variables.  Is this by design or
accident?


Gary Wright
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-12-22 02:58
(Received via mailing list)
Hi --

On Fri, 22 Dec 2006, gwtmp01@mac.com wrote:

> There are now two distinct class variables named @@avar, one is associated
> with Object and another is associated with class A and shadows the one
> associated with Object.

Yes -- basically, if you create the class variable in the subclass
first, then it's different from the one in the superclass.  Mind you,
a lot of this is scheduled to change in 2.0.  I fear, though that the
confusion caused by class variables will persist.  A class variable is
going to be (as I understand it) more similar to an instance variable
than it is now, but with visibility to instances of the class.  A lot
of the problem with class variables is that they cloud the matter of
classes being objects and having their own instance variables.  I'm
not sure whether these changes will change that.

(When I say they cloud it, I'm basing this on six years of watching
person after person after person have trouble grasping this area of
Ruby, and it's always something like, "Wait -- doesn't a class have
*class* variables?  If they're analogous to instance variables for
instances, then what are they?"  It can be explained, of course (I've
done it many times :-) but there's definitely something in the
behavior that makes this harder to get than most other language
features.)

> I still don't understand why class_eval/instance_eval don't affect the
> resolution of class variables in a manner analogous to how they affect the
> resolution of instance variables.  Is this by design or accident?

See David Goodlad's explanation; I think it's by design.  class_eval
brings about a scope that's like a 'class' block in some ways but not
in others.  The surrounding class and local variables can permeate
their way in.


David
55c843cb14d7521d933a0780dbb8f4a5?d=identicon&s=25 Brock Lee (Guest)
on 2007-01-06 19:18
(Received via mailing list)
So, would it be fair to say that you won't run into difficulties with
class variables (denoted with @@) if:

    a. you assign class variables in the superclass before assigning
them in the sublcass, and
    b. you don't expect class_eval to provide access to them?

Or are there other areas of confusion?

Thanks,

Brock
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-01-06 19:18
(Received via mailing list)
On 12/21/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

>    A.class_eval { puts @@avar }  # => hello
>
> I love Ruby madly, but (or "therefore"? :-) I would be happy never to
> see another class variable again.  The confusingness-to-usefulness
> ratio is extremely high.

Wow David, that is scary.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2007-01-06 19:30
(Received via mailing list)
Hi --

On Sat, 6 Jan 2007, Brock Lee wrote:

> So, would it be fair to say that you won't run into difficulties with
> class variables (denoted with @@) if:
>
>    a. you assign class variables in the superclass before assigning
> them in the sublcass, and

Assuming you understand that when you assign them in the subclass,
you're assigning to the exact same variable, throughout the hierarchy.

>    b. you don't expect class_eval to provide access to them?
>
> Or are there other areas of confusion?

The most important lesson to learn about class variables, I believe,
is that they have *nothing* to do with instance variables.  They're
not a replacement for them; they're not the equivalent for classes
(instance variables exist for classes); and the @/@@ thing is purely
cosmetic.

The reason I say this is that most of the confusion I've seen over the
years has to do with class variables getting in the way of
understanding instance variables, since they lead people to assume
that the idea of a class having an instance variable is meaningless
(since there are already class variables...).  That, in turn, makes it
much harder to understand instance variables.


David
5aaaaeaa5771aa96f953228a74f0966b?d=identicon&s=25 Rob Muhlestein (Guest)
on 2007-01-06 19:31
(Received via mailing list)
dblack@wobblini.net wrote:
> You had me at "I generally avoid class variables" :-)
> ...snip...
> I love Ruby madly, but (or "therefore"? :-) I would be happy never to
> see another class variable again.  The confusingness-to-usefulness
> ratio is extremely high.

David and gang, thanks for pulling me out of denial.

[Here's a blog post about my facing reality, finally:
http://rob.muhlestein.net/2007/01/ruby-class-varia...]

Rob
5aaaaeaa5771aa96f953228a74f0966b?d=identicon&s=25 Rob Muhlestein (Guest)
on 2007-01-19 16:30
(Received via mailing list)
Rob Muhlestein wrote:
> http://rob.muhlestein.net/2007/01/ruby-class-varia...]
After reading the comments in the response it is probably worth
mentioning in this thread that class *variable* scope inheritance is
changing between 1.8 and 1.9/2.0 (as noted in the pickax). I ran an irb
confirmation of this and posted results there to make sure.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-01-19 16:31
(Received via mailing list)
On 1/5/07, Rob Muhlestein <rob@muhlestein.net> wrote:
> http://rob.muhlestein.net/2007/01/ruby-class-varia...]
I blogged it too, though mine is mostly just a quick paste of the two
bits of code from David and Gary, and a link to your blog entry.  My
NubyGems series is usually like that, a big chunk of code from an IRB
session meant to make people go 'whoa, yeah, that does suck'

http://www.oreillynet.com/ruby/blog/2007/01/nubyge...
This topic is locked and can not be replied to.