From: stern@... (Alan Stern)
Date: 2002-02-12T00:30:51+09:00
Subject: Re: Class variable madness

matz@ruby-lang.org (Yukihiro Matsumoto) wrote in message news:<1013369626.565272.19418.nullmailer@ev.netlab.jp>...
> In message "Class variable madness"
>     on 02/02/11, Alan Stern <stern@rowland.org> writes:
> 
> |a.rb(main):028:0* A.set(3)
> |NameError: uninitialized class variable @@v in A
> |	from a.rb:8:in `set'
> |	from a.rb:28
> |
> |		# Why didn't that work?
> 
> Because you didn't prepare @@v in A.  No @@v is known for class A.  The
> class variable references are resolved statically as much as possible.

Matz, I guess I didn't express my meaning very clearly.  What I want
to know is this:  If @@v has not yet been defined as a class variable
for class A, then why should assigning to @@v in a class method fail
whereas assigning to @@v in an instance method works?  Why shouldn't
these either both fail or both work?  What is the reason for this
inconsistent behavior?

Here is another, related question.  If @@v has been defined as a class
variable for class A, and if B is derived from A, then it is
impossible (in Ruby 1.6.5, at least) to define a class variable named
@@v within B.  Any attempt to do so will merely overwrite the value of
@@v within A, rather than creating a new, separate value within B.  Is
this the intended behavior?  And what is the reason for this?

Is it possible that these are not really how class variables were
intended to work but are merely artifacts or side-effects of the
Ruby-1.6.5 implementation?

Alan Stern