From: matz@... (Yukihiro Matsumoto)
Date: 2002-02-12T01:36:19+09:00
Subject: Re: Class variable madness

Hi,

In message "Re: Class variable madness"
    on 02/02/12, Alan Stern <stern@rowland.org> writes:

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

Oops, "a.set(5)" should fail just like "A.set(5)".

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

That's what class variables are.  Class variables are variables to be
shared among class hierarchy.  They are not only shared by instance of
the class, but also shared by instances of subclasses.  As a result,
you cannot define class variables of same names in subclass.

							matz.