From: Gavin Sinclair Date: 2003-08-13T14:37:03+09:00 Subject: Re: Nested class/module namespace > [Nathaniel wrote:] > If the reason is implementation difficulty, I can understand that... but > I worry that the differences between > > module M > class C > end > end > > and > > class M::C > end > > will confuse many a newbie (and some oldies, too). > > Can you help me understand why the current behavior is better? Well put. I'll throw my 10c in as well. Ruby has a model where everything, including class and method definition, happens at runtime. Thus you can have any code you like executed during the definition of a class, e.g. class Example 10.times { |i| puts i } end Another important part of Ruby's model is that there is *always* a variable called "self", which forms part of the execution context of any code. For instance: class Example def self.foo -1 end end Example.foo # -> -1 Now, "self" is the same thing in both the following cases: module X class Y self # 1 end end class X::Y self # 2 end Finally, to the point. Nathaniel has identified a difference between the two cases above when one tries to access a constant, say X::C (which is not defined in the above code). If there is a difference, then there must be a difference in the "execution context". To my way of thinking, the only thing that should be important in an execution context is the value of "self". If that is not the case, we need an explanation, and probably a justification. At the moment, I think the elegance of Ruby is being stretched a bit. Cheers, Gavin PS. Here's some irb output to demonstrate the issue in case anyone needs to see it again. # ----------------- CASE 1 ----------------- # module X C = 5 class Y puts C # prints "5" end end # ----------------- CASE 2 ----------------- # module M C = 5 end module M class N puts C # prints "5" end end # ----------------- CASE 3 ----------------- # module A C = 5 end class A::B puts C # NameError: uninitialized constant A::B::C end # ------------------ END ----------------- #