[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Class Variable Confusion

Gary Wright

12/21/2006 9:05:00 PM

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
21 Answers

dblack

12/21/2006 9:44:00 PM

0

David Goodlad

12/21/2006 10:03:00 PM

0

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

>
> On 12/21/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
> >
> > Hi --
> >
> > On Fri, 22 Dec 2006, gwtmp01@mac.com wrote:
> >
> > > 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?
> >
> > 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
> >
> > --
> > Q. What's a good holiday present for the serious Rails developer?
> > A. RUBY FOR RAILS by David A. Black (http://www.manning...)
> > aka The Ruby book for Rails developers!
> > Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
> > A. Ruby Power and Light, LLC (http://www.r...)
> >
> >
>
>


--
Dave Goodlad
dgoodlad@gmail.com or dave@goodlad.ca
http://david.g...

Gary Wright

12/22/2006 12:09:00 AM

0


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

dblack

12/22/2006 1:57:00 AM

0

Rob Muhlestein

1/5/2007 2:27:00 PM

0

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-variables-just-dont-go-...]

Rob

Gregory Brown

1/5/2007 6:10:00 PM

0

On 12/21/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

> 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.

Wow David, that is scary.

Rob Muhlestein

1/5/2007 6:24:00 PM

0


Rob Muhlestein wrote:
> 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-variables-just-dont-go-...]

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.

Gregory Brown

1/5/2007 6:44:00 PM

0

On 1/5/07, Rob Muhlestein <rob@muhlestein.net> wrote:
> 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-variables-just-dont-go-...]

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/nubygems_dont_use_class_var...

Brock Lee

1/5/2007 10:12:00 PM

0

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

dblack

1/5/2007 10:42:00 PM

0