Actions
Bug #11705
closedNamespace resolution in nested modules with short syntax
Description
Given the following definition:
module Foo
class Qux
def self.hello
'Hello, world!'
end
end
end
Namespace resolution at a later time works differently when you have nested modules, e.g.
module Foo
module Bar
# Can't find Foo::Bar::Qux, so "goes up" to find Foo::Qux.
p Qux.hello # < "Hello, world!"
end
end
vs. the short syntax, e.g.
module Foo::Bar
# Can't find Foo::Bar::Qux, but doesn't "go up" to find Foo::Qux.
p Qux.hello # < in `<module:Bar>': uninitialized constant Foo::Bar::Qux (NameError)
end
Is this intentional and/or expected?
Updated by shugo (Shugo Maeda) almost 9 years ago
- Status changed from Open to Rejected
Mike Pastore wrote:
Is this intentional and/or expected?
It's intentional and expected.
If class and/or module definitions are explicitly nested, constants of outer classes and/or modules are looked up.
However, if a class or module definition is not nested, only constants in the class or module, its ancestors,
and if the target is a module, Object
and Object
's ancestors are looked up.
You can see module nesting information by Module.nesting
.
module Foo
module Bar
p Module.nesting #=> [Foo::Bar, Foo]
p Qux.hello #=> "Hello, world!"
end
end
module Foo::Bar
p Module.nesting #=> [Foo::Bar]
p Qux.hello #=> NameError, because Foo is not included in Module.nesting
end
Updated by mame (Yusuke Endoh) almost 5 years ago
- Has duplicate Feature #16430: Resultion of constants in enclosing class/module affected by how nested classes/modules are declared added
Actions
Like0
Like0Like0