Bug #6374: Acces to initialized class variable from included module

• Status: Rejected
• Assignee: -
• Target version: 1.9.3
• ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux]

[Sega100500 (Сергей Е)]

Description of bug (?) below in comments of code

May by it is not a bug, but feature ?

module Variables

def print_var
	print "In module #{self.class.name}: #{@variable}\n"
end

def print_class_var
	print "In module class-variable #{self.class.name}: #{@@class_variable}\n"
end

def set_variables(var, cvar)
	@variable = var
	@@class_variable = cvar
end

end

class A

include Variables

def initialize(var, cvar)
	@variable = var
	@@class_variable = cvar
end

def print_variables
	print "variables: #{@variable}, #{@@class_variable}\n"
end

def self.print_class_a_variables
	print "Class '#{self.class.name}' variable: #{@@class_variable}\n"
end

end

class B < A
end

a = A.new(123, 456)

A.print_class_a_variables
B.print_class_a_variables

a.print_variables

a.print_var

a.print_class_var # fail: :8:in print_class_var': uninitialized class variable @@class_variable in Variables (NameError) # Why? I set '@@class_variable in 'initialize'

a.set_variables(12, 33) # Once again set '@@class_variavle'

a.print_class_var # But this method is tested

[Sega100500 (Сергей Е)]

And more:
If then at the end to execute 'a.print_variables', we will receive values which set in 'a.set_variables_a (12, 33)'

[nobu (Nobuyoshi Nakada)]

It's a spec.
Class variables belong to the static scope of classes, as well as constants.

[Sega100500 (Сергей Е)]

Then why in 'set_variables' (module Variables) is set @@class_variable for class 'A', appropriates to a class variable value? The second call (at the end of program) of a.print_variables already displays the changed values.

[mame (Yusuke Endoh)]

• Status changed from Open to Feedback

I guess this is where "the Standard" comes in.
Anyone who can check ISO/IEC 30170 ? I don't have ;-)

--
Yusuke Endoh [e-mail]

[shugo (Shugo Maeda)]

mame (Yusuke Endoh) wrote:

I guess this is where "the Standard" comes in.
Anyone who can check ISO/IEC 30170 ? I don't have ;-)

The current behavior is conforming to ISO/IEC 30170.

In "11.5.4.5 Class variables" of ISO/IEC 30170:

A class-variable-identifier is evaluated as follows:
a) Let N be the class-variable-identifier. Let C be the first class or module in the list at the top of [class-module-list] which is not a singleton class.
b) Let CS be the set of classes which consists of C and all the superclasses of C. Let MS be the set of modules which consists of all the modules in the included module list of all classes in CS. Let CM be the union of CS and MS.
c) If a binding with name N exists in the set of bindings of class variables of only one of the classes or modules in CM, let V be the value of the binding.
d) If more than two classes or modules in CM have a binding with name N in the set of bindings of class variables, let V be the value of one of these bindings. Which binding is selected is implementation-defined.
e) If none of the classes or modules in CM has a binding with name N in the set of bindings of class variables, let S be a direct instance of the class Symbol with name N and raise a direct instance of the class NameError which has S as its name attribute.
f) The value of the class-variable-identifier is V.

, where [class-module-list] is a stack of lists who represent the basically same information as Module.nesting.

[mame (Yusuke Endoh)]

• Status changed from Feedback to Rejected

shugo (Shugo Maeda) wrote:

mame (Yusuke Endoh) wrote:

I guess this is where "the Standard" comes in.
Anyone who can check ISO/IEC 30170 ? I don't have ;-)

The current behavior is conforming to ISO/IEC 30170.

Thanks Shugo!
We then need "very good reason" to change this behavior.
Please reopen this ticket if you have.

--
Yusuke Endoh [e-mail]