From: "Chr. Rippel" <chr_news@...>
Date: 2002-02-08T05:24:10+09:00
Subject: Re: Class variable bug


"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in
> Hi,
....
> First of all, if you put '-v' option to the interpeter, it warns you
> about class variables, that means it might not work as you expected.

Isn't this mainly to warn me about something like ...  

class A; end 
class B < A 
    @@var = 'still b'
end
class A
    @@var = 'a'
end
class B
   @@var  # => 'still b'
end
 
 
> In this case "@@var" is a class variable of surrounding class (unnamed
> singleton class attached to A), whereas
> 
> |class A 
> |    def A.first_form; @@var end
> |end
> 
> "@@var" is a class variable of surrounding class (A).

I am actually not quite sure what the difference between a class
variable for A and a class variable for ``meta A'' is supposed
to be?  Assuming normal usage once I define a class variable
for A it is also accessible in ``meta A'' and vice versa. For example,

----
class A; end
a = A.new

class << A; self end.class_eval { @@var = 3 }
A.instance_eval { p @@var }    #  => 3
A.class_eval { p @@var }         #  => 3 
a.instance_eval { p @@var }     #  => 3
----

That said, it might be a cleaner to strictly distinguish between normal
class variables and class variables on the meta level? (this change 
would certainly break some of my own scripts..)

> This behavior difference is arguable.  Since "class << self" form can
> be considered as short hand of singleton methods definitions, you can
> say it is better to have same behavior to singleton methods.  It can
> be implemented by simply removing one line from eval.c.  I'm open to
> discussion.
 
Well I prefer uniform behavior in general and in this particular case the usage
of ``class << self'' over a ``single singleton method'' definition only has an
effect in some obscure situation down the road - so as long as this would
not effect the current very logical treatment of constants I would not mind
if you would drop this line.

/Christoph