Bug #1469: Different behavior of class variables in 1.9.0 and 1.9.1p129

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: 1.9.2
• ruby -v: ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]

[biteme (Kenneth Ballou)]

=begin
The code in the attached file (classvars.rb) is based on the discussion of class variables on pages 337 and 338 of "Programming Ruby 1.9". I ran the code using ruby 1.9.0 and ruby 1.9.1p129. The output was different for the two versions, and both differ from what the book says it should be.

For 1.9.0: ruby -v reports "ruby 1.9.0 (2006-06-08) [x86_64-linux]"
For 1.9.1: ruby -v reports "ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]"

Output from ruby 1.9.0:

a.var: 99
a.var: 123
a.get_var: top level variable
@@var: top level variable
Holder.read_var: 123

Just in case attaching the file classvars.rb doesn't work, here is its contents:

begin classvars.rb

class Holder
@@var = 99
def Holder.var=(val)
@@var = val
end
def Holder.read_var
@@var
end
def var
@@var
end
end

@@var = "top level variable"

a = Holder.new
puts "a.var: #{a.var}"
Holder.var = 123
puts "a.var: #{a.var}"

def a.get_var
@@var
end

puts "a.get_var: #{a.get_var}"
puts "@@var: #{@@var}"
puts "Holder.read_var: #{Holder.read_var}"

end classvars.rb

Output from ruby 1.9.1p129:

a.var: top level variable
a.var: 123
a.get_var: 123
@@var: 123
Holder.read_var: 123

If I understand the book correctly, the expected output would be:

a.var: top level variable
a.var: 123
a.get_var: top level variable
@@var: top level variable
Holder.read_var: 123

(I'm not sure I understand why the first call to a.var would return the string "top level variable" but the second call would return the Fixnum 123. However, that's not part of this issue report.)
=end

[headius (Charles Nutter)]

=begin
Kenneth Ballou wrote:

If I understand the book correctly, the expected output would be:

a.var: top level variable
a.var: 123
a.get_var: top level variable
@@var: top level variable
Holder.read_var: 123

(I'm not sure I understand why the first call to a.var would return the string "top level variable" but the second call would return the Fixnum 123. However, that's not part of this issue report.)

I hate class variables. JRuby looks different as well:

➔ jruby classvars.rb
a.var: 99
a.var: 123
a.get_var: top level variable
@@var: top level variable
Holder.read_var: 123

First line seems like what I'd expect to see, honestly. The others match
"expected" results, but a.get_var confuses me a bit (would expect it to
see "123").

• Charlie

=end

[yugui (Yuki Sonoda)]

• Assignee set to matz (Yukihiro Matsumoto)
• Target version set to 1.9.2

=begin

=end

[wanabe (_ wanabe)]

=begin

The code in the attached file (classvars.rb) is based on the discussion of class variables on pages 337 and 338 of "Programming Ruby 1.9". I ran the code using ruby 1.9.0 and ruby 1.9.1p129. The output was different for the two versions, and both differ from what the book says it should be.

It's intentional, applied by r13604.
And Matz mentioned about the change in [ruby-dev:32260].
(sorry, it is written in Japanese)

Matz, do you mind if I ask you the how and why about it?
=end

[mame (Yusuke Endoh)]

• Status changed from Open to Rejected

=begin
Hi,

For 1.9.0: ruby -v reports "ruby 1.9.0 (2006-06-08) [x86_64-linux]"

This is the development version of 1.9.0 that had never been released
yet. The release version 1.9.0-0 (2007-12-26) behaves the same way of
1.9.1p129.

So, this ticket is completely invalid. Thus I close.

FYI, the spec of class variable scope was changed between 1.8 and 1.9.
When class variable of the same name is defined in the parent class,

• 1.8: the original variable remains.

• 1.9: the original variable disappears.

  class C
  end
  class D < C
  @@foo = :D
  end
  class C
  @@foo = :C
  end
  class D
  p @@foo #=> :D in 1.8, :C in 1.9
  end

According to the draft of ruby-std, it is implementation defined when
the class variable scope is ambiguous.

Anyway, this is certainly intended change, though I don't know the
rationale.
If you are just curious about the rationale, please ask matz in ruby-
core ML or directly in somewhere conference.
If you have some real problem caused by this change, please reopen the
ticket with the problem explanation.

--
Yusuke ENDOH [e-mail]
=end