I'm reviving a thread from September.

Matz: in early October, you changed variable.c, fixing the bug that Eric 
reported on this thread.  In doing so, you reverted class variables to 
their 1.8 behavior: they're now shared among classes, and if a subclass 
sets an inherited class variable it is setting the value in the 
superclass rather than creating a new class variable of its own.

I've just noticed this and wanted to confirm that it was an intended 
change and not an accidental regression before I edit my book to remove 
the description of the 1.9 behavior that you've reverted.

	David

David Flanagan wrote:
> Eric,
> 
> I'm sorry; I completely mis-understood your point, and my response was 
> completely off-mark.  (And it may also have insulted your intelligence. 
>  Sorry!)
> 
> It does seem to me as if you've uncovered a bug.  Note that if you 
> change your code as follows it behaves in the way you would expect:
> 
> module X
>   @@cv1 = 'cv1'
> 
>   class << self
>     def cv1() @@cv1 end
>   end
> 
>   def self.cv1=(obj) @@cv1 = obj end
> end
> 
> Perhaps this is a clue to the origin of the bug.
> 
>     David
> 
> Eric Hodel wrote:
>> On Sep 20, 2007, at 10:49, David Flanagan wrote:
>>> I think this is just one manifestation of the fact that class 
>>> variables are no longer shared between classes and subclasses. That 
>>> is: I don't think the behavior you're seeing is specific to singletons.
>>
>> My concern is not how widespread this behavior is, its that defining a 
>> class variable accessor in two different ways gives two different 
>> results, and you mixing the two causes head-scratching.
>>
>> If this is intended, fine.
>>
>> -- 
>> Poor workers blame their tools. Good workers build better tools. The
>> best workers get their tools to do the work for them. -- Syndicate Wars
>>
>>
>>
> 
>