Bug #6374

Acces to initialized class variable from included module

Added by Сергей Е almost 2 years ago. Updated over 1 year ago.

[ruby-core:44717]
Status:Rejected
Priority:Normal
Assignee:-
Category:-
Target version:1.9.3
ruby -v:ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux] Backport:

Description

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.printclassavariables
B.print
classavariables

a.print_variables

a.print_var

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

a.setvariables(12, 33) # Once again set '@@classvariavle'

a.printclassvar # But this method is tested

attr_module2.rb Magnifier (998 Bytes) Сергей Е, 04/28/2012 01:53 PM


Related issues

Related to Backport93 - Backport #6918: Fix for webrick test failures on mswin32 Closed 08/24/2012

History

#1 Updated by Сергей Е almost 2 years ago

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

#2 Updated by Nobuyoshi Nakada almost 2 years ago

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

#3 Updated by Сергей Е almost 2 years ago

Then why in 'setvariables' (module Variables) is set @@classvariable 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.

#4 Updated by Yusuke Endoh almost 2 years ago

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

#5 Updated by Shugo Maeda over 1 year ago

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.

#6 Updated by Yusuke Endoh over 1 year ago

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

Also available in: Atom PDF