[#68845] [Ruby trunk - Feature #11056] [PATCH] lib/net/*: use io/wait methods instead of IO.select — normalperson@...
Issue #11056 has been updated by Eric Wong.
3 messages
2015/04/11
[#68945] [Ruby trunk - Feature #11083] [Open] Gemify net-telnet — shibata.hiroshi@...
Issue #11083 has been reported by Hiroshi SHIBATA.
4 messages
2015/04/21
[#68951] Re: [Ruby trunk - Feature #11083] [Open] Gemify net-telnet
— Eric Wong <normalperson@...>
2015/04/21
shibata.hiroshi@gmail.com wrote:
[#69012] [Ruby trunk - Feature #11105] [Open] ES6-like hash literals — shugo@...
Issue #11105 has been reported by Shugo Maeda.
5 messages
2015/04/29
[ruby-core:68890] [Ruby trunk - Bug #10702] Constant look up inconsistency with constants defined in included modules
From:
kwstannard@...
Date:
2015-04-14 15:06:46 UTC
List:
ruby-core #68890
Issue #10702 has been updated by Kelly Stannard.
Kelly Stannard wrote:
> ~~~
> module A; module B; end; end
>
> module X
> include A
> end
>
> puts X::B # => A::B
>
> module X
> puts B # => A::B
>
> module Y
> puts B # => NameError: uninitialized constant X::Y::B
> end
> end
> ~~~
Okay, so I re-reading the blog post a 5th time, I think I get that `module X; B; end` is using ancestry and not lexical, which would explain why `module X; module Y; B; end; end` fails. I don't get why `X::B` works though as it is not within X and therefor does not get to take advantage of X's ancestry lookup.
----------------------------------------
Bug #10702: Constant look up inconsistency with constants defined in included modules
https://bugs.ruby-lang.org/issues/10702#change-52159
* Author: Kelly Stannard
* Status: Rejected
* Priority: Normal
* Assignee:
* ruby -v: 2.2-head
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
https://gist.github.com/kwstannard/c0f722976ba023cc5755
```ruby
module A
module B
end
end
module C
include A
puts B.inspect # => A::B
class D
puts B.inspect rescue puts 'failed' # => failed
end
B = B
class E
puts B.inspect # => A::B
end
end
```
When you include a module you gain access to that module's constants as seen in line 9. Line 19 shows that you can get constants defined in the nested module when the constant is defined within the module itself.
Line 12 is the bug. Shouldn't class `D` be able to access module `B` since the previous line shows that module `C` has access to Module `B`?
--
https://bugs.ruby-lang.org/