Project

General

Profile

Bug #1469

Different behavior of class variables in 1.9.0 and 1.9.1p129

Added by biteme (Kenneth Ballou) over 11 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
Normal
Target version:
ruby -v:
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
Backport:
[ruby-core:23452]

Description

=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


Files

classvars.rb (400 Bytes) classvars.rb biteme (Kenneth Ballou), 05/15/2009 04:26 AM
#1

Updated by headius (Charles Nutter) over 11 years ago

=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

#2

Updated by yugui (Yuki Sonoda) over 11 years ago

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

=begin

=end

#3

Updated by wanabe (_ wanabe) almost 11 years ago

=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

#4

Updated by mame (Yusuke Endoh) over 10 years ago

  • 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 mame@tsg.ne.jp
=end

Also available in: Atom PDF