Re: confusion with class_eval

Hi,

Note that the effect you are seeing doesn't occur in this case:

class A
  @@x = 10
end

puts A.class_variable_get(:@@x)
puts Object.class_variable_get(:@@x)

--output:--
10
1.rb:6:in `class_variable_get': uninitialized class variable @@x in 
Object (NameError)
  from 1.rb:6:in `<main>'

So the problem does have to do with class_eval. I don't have a 
definitive explanation of what's going on, but "Metaprogramming Ruby" 
teaches us that class_eval changes self to the receiver, and the 
'current class' also changes to the receiver as well.  Based on that 
'rule', it would be natural to assume that class variables appearing for 
the firs time inside the block would attach to the current class. 
However, that is clearly not the case.

Because the problem manifests itself when you use a block (as part of 
your class_eval), the block is the key to the problem.  Blocks are 
closures, which means they can see the variables defined in the 
surrounding code.  Blocks can also change the values in the surrounding 
code.  Here is an example of that:

x = 10
code = lambda {puts x; x = 'hello'}

code.call
puts x

--output:--
10
hello


In your case, the surrounding code is the 'top level' where an object 
called 'main' exists (created by ruby at startup), and main is an object 
of class Object.  So your block can see those things in the surrounding 
scope, or, in other words, your block travels around with a 'binding' 
that includes all the variables in the surrounding code and their 
values.  I think ruby must look for something in the binding  to attach 
class variables to--rather than using the 'current class'.

Your output shows that the class variable attaches to the class Object, 
but the details of how that works are not clear to me.   However, the 
fact that class variables leak out of a block seems like yet another 
reason not to use class variables.

-- 
Posted via http://www.ruby-forum.com/.