A research on ruby constant lookup path Problem _ruby Special topic

Ruby's constant lookup path problem is a problem that's been bothering me, in the work encountered several times, has not thoroughly understand why, recently read a book "Ruby Metaprogramming", the Ruby object model has a deeper understanding, and read a blog "Everything You Ever wanted to know about constant lookup in Ruby, let me finally get a clearer idea of the Ruby constant lookup path.

The first problem I encountered, I have also been posted on the Ruby-china.

Copy Code code as follows:

Module M1
CT = "OK"
End

Class C1
ck = "CK"
Include M1

def self.method1
Puts self
Puts "#{ck} in Method1"
Puts "#{ct} in Method1"
End

Class << Self
def METHOD2
Puts self
Puts "#{ck} in Method1"
Puts "#{ct} in Method2"
End
End
End

C1.method1
C1.method2

The output result is

Copy Code code as follows:

C1
CK in Method1
OK in method1
C1
CK in METHOD2
NAMEERROR:UNINITIALIZED constant CLASS::CT
From (IRB): 16:in ' method2 '

This is the problem I encountered while refactoring the Mint code, METHOD1 and METHOD2 are common definitions of class methods, which I've always considered to be equivalent and replaceable, but from the actual results, the constant lookup paths are different.

If I change the definition of M1 to the following:

Copy Code code as follows:

Module M1
def self.included (Base)
Base.extend (self)
End
CT = "OK"
End

The results of the execution are:

Copy Code code as follows:

C1
CK in Method1
OK in method1
C1
CK in METHOD2
OK in method2

There is also a problem that is often encountered, the abstract problematic code is as follows:

Copy Code code as follows:

Module A
Module M
def A_method
#...
End
End
End

Class A::b
Include M
End

Will report an exception:

Copy Code code as follows:

NAMEERROR:UNINITIALIZED constant A::b::m
From (IRB): 10:in ' <class:B> '

Ruby Constant lookup is based on two paths

A. module.nesting
B. Open Class/module's ancestors

A is preferable to B, and a is not found in B.

A.module.nesting's concept is easy to understand, it refers to the code location of the Module nesting situation, it is an array, from the outermost nesting to the outermost nesting, if there is no nesting, the array is empty. Any location of the code has a module.nesting value, you can print out the module.nesting values in each location by using the following code.

Copy Code code as follows:

P module.nesting

Module A
Module B
P module.nesting
Module C
P module.nesting
End
End
End

Module A::B
P module.nesting
End

The output is:

Copy Code code as follows:

[]
[A::b, A]
[A::b::c, A::b, A]
[A::b]

Have you noticed that the module a::b this shortcut notation causes A not to be in module.nesting, which is the root of the second problem because M is a constant under a module, and the module a::b writing causes the a::m to not be found.

Finish a module.nesting, say again the B open class/module ancestors, this problem is relatively complex. Simply put, there is a self existence in any position of the Ruby code, and there is also an open class/module, which, at the module and class definition, is usually the corresponding module and class, within the method, which is the corresponding class of the method. For ancestors, we can get it through the ancestors method of the open class/module of the code position.

(Note: Ancestors becomes a bit more complicated after introducing the Singleton_class concept, such as "Ruby metaprogramming")

The first question above: in Method1 A is [C1] Open class/module is C1, so ancestors is [C1, M1, Object, Kernel, Basicobject] CK can be found in a, CT in B can be found.

Method2 A is [C1] Open Class/module is C1 singleton_class, so ancestors is [class, module, Object, Kernel, Basicobject] CK can be found in a, CT is not found in a and B.

For

Copy Code code as follows:

Module M1
def self.included (Base)
Base.extend (self)
End
CT = "OK"
End

Can be run because then, in Method2, the singleton_class of the Open Class/module C1 expands M1, so ancestors becomes a [M1, class, module, Object, Kernel, B Asicobject].

At this point, the two problems that have plagued me have been thoroughly figured out. This process gives me a experience is: face technical questions, if only a little, is never really grasp it, only in-depth research, a thorough understanding of its principles, can really grasp it, to achieve real ability to upgrade.