Forum: Ruby Module Eval Syntax

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
6ec6f77ea603dd75b3a7a7775b059e79?d=identicon&s=25 John W. Long (Guest)
on 2006-01-26 21:17
(Received via mailing list)
>> class MyModule; end
=> nil
 >> MyModule.class_variables
=> []
 >> MyModule.module_eval do
?>   @@test = true
 >> end
=> true
 >> @@test
=> true
 >> MyModule.module_eval "@@weird = true"
=> true
 >> @@weird
NameError: uninitialized class variable @@weird in Object
         from (irb):8
 >> MyModule.class_variables
=> ["@@weird", "@@test"]
 >> Object.class_variables
=> ["@@test"]

What in the world is going on here? Why does the block syntax eval
differently than the string syntax? And why does @@test get defined on
both MyModule and Object?
A9b6a93b860020caf9d2d1d58c32478f?d=identicon&s=25 Ross Bamford (Guest)
on 2006-01-26 22:53
(Received via mailing list)
This isn't a direct answer to John's question, but more an expansion of
it that came up while I was playing with the original and my theory on
what's going on. Considering this IRB:

	module MyModule; end
	# => nil

	MyModule.module_eval do
	  @@mod_eval_var = "mev"
	# => "mev"

	MyModule.instance_eval do
	  @@inst_eval_var = "iev"
	# => "iev"

	def MyModule.mkcv
	  @@sing_meth_var = "smv"
	# => nil

	# => "smv"

	module MyModule
	  def self.mkcv2
	    @@cls_sing_meth_var = "csmv"
	# => nil

	# => "csmv"

	# => ["@@mod_eval_var", "@@inst_eval_var", "@@sing_meth_var"]
	# => ["@@mod_eval_var", "@@inst_eval_var", "@@sing_meth_var"]
	# => ["@@mod_eval_var", "@@inst_eval_var", "@@sing_meth_var"]
	# => ["@@cls_sing_meth_var"]

Let me explain what I think I'm seeing here, and see if anyone can steer
me right or expand on this behaviour. As far as I can tell, it seems
that any time you make a @@class_var outside of an actual class / module
definition, you have to be extremely careful that you're actually
defining where you think you are. I would guess that any time Ruby sees
an @@ variable, it immediately goes to the enclosing class and defines
the variable there. Maybe that explains the block behaviour, because
although the blocks are evaluated in the module they somehow retain
their original enclosing object's class - the top-level object in this
case, of class Object.

The singleton method definition (def MyModule.mkcv) is actually creating
a method on MyModule's singleton class, which is just an instance of
Class. The new method becomes an 'instance method' of that singleton
class, so that @@sing_meth_var = "smv" results in Class (the #class of
the singleton Class instance) getting another class variable. This is
demonstrated by:

	sc = module MyModule
	  class << self; self; end
	# => #<Class:MyModule>
	# => Class
	# => ["@@mod_eval_var", "@@inst_eval_var", "@@sing_meth_var"]

If this is true, then it explains why the class variables are present
across Object, Class and Module's class variables - since all are
instances of Class (and #class_variables shows inherited vars). Since
MyModule (an instance of class Module, a superclass of Class) doesn't
see these variables, I have to assume they do end up defined on Class.
More generally, once a class variable is defined on either Class or
Object (each being the class of the other) it is to all intents and
purposes defined everywhere, given the class_variables behaviour I
mentioned above.

The final mkcv2 definition, by virtue of being inside a reopened module
definition, *is* defined as a a singleton method on MyModule, but either
doesn't go to the singleton class (instead being actually redefined on
the Module instance), or else is treated specially (which I somehow
doubt but is possible). In any event, this ends up being defined where
we'd expect it.

To further check out the line between a class and it's singleton class,
I did a further experiment:

	class SomeClazz
	  @@icv = "icv"
	# => "icv"

	# => ["@@icv", "@@mod_eval_var", "@@inst_eval_var", "@@sing_meth_var"]

	# => ["@@mod_eval_var", "@@inst_eval_var", "@@sing_meth_var"]

	def SomeClazz.cval
	# => nil

	NameError: uninitialized class variable @@icv in Object
	        from (irb):90:in `cval'
	        from (irb):92
	        from :0

	class SomeClazz
	  def self.mcval
	# => nil

	# => "icv"

This seems to confirm what I said above, and also (to me) is another
great reason to stay away from class variables, especially when you're
talking about class variables on Class or Module instances.

Anyway, this is just theory of course, and especially with the block
it seems pretty mysterious - maybe even "surprising" - but it would seem
to fit I think - A string eval obviously doesn't close over it's scope
wouldn't be affected by it I guess. I hope someone can shed some more
more light on this because it's going to bug me now ;)
This topic is locked and can not be replied to.