* [ruby-core:71532] [Ruby trunk - Bug #11705] [Open] Namespace resolution in nested modules with short syntax
[not found] <redmine.issue-11705.20151117232835@ruby-lang.org>
@ 2015-11-17 23:28 ` mike
2015-12-18 8:30 ` [ruby-core:72359] [Ruby trunk - Bug #11705] [Rejected] " shugo
1 sibling, 0 replies; 2+ messages in thread
From: mike @ 2015-11-17 23:28 UTC (permalink / raw)
To: ruby-core
Issue #11705 has been reported by Mike Pastore.
----------------------------------------
Bug #11705: Namespace resolution in nested modules with short syntax
https://bugs.ruby-lang.org/issues/11705
* Author: Mike Pastore
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v:
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
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?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
* [ruby-core:72359] [Ruby trunk - Bug #11705] [Rejected] Namespace resolution in nested modules with short syntax
[not found] <redmine.issue-11705.20151117232835@ruby-lang.org>
2015-11-17 23:28 ` [ruby-core:71532] [Ruby trunk - Bug #11705] [Open] Namespace resolution in nested modules with short syntax mike
@ 2015-12-18 8:30 ` shugo
1 sibling, 0 replies; 2+ messages in thread
From: shugo @ 2015-12-18 8:30 UTC (permalink / raw)
To: ruby-core
Issue #11705 has been updated by Shugo Maeda.
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
```
----------------------------------------
Bug #11705: Namespace resolution in nested modules with short syntax
https://bugs.ruby-lang.org/issues/11705#change-55652
* Author: Mike Pastore
* Status: Rejected
* Priority: Normal
* Assignee:
* ruby -v:
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
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?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-12-18 7:58 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <redmine.issue-11705.20151117232835@ruby-lang.org>
2015-11-17 23:28 ` [ruby-core:71532] [Ruby trunk - Bug #11705] [Open] Namespace resolution in nested modules with short syntax mike
2015-12-18 8:30 ` [ruby-core:72359] [Ruby trunk - Bug #11705] [Rejected] " shugo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).