From: matz@... (Yukihiro Matsumoto)
Date: 2003-02-20T02:37:38+09:00
Subject: Re: module This::Encompassing::That

Hi,

In message "Re: module This::Encompassing::That"
    on 03/02/20, dblack@candle.superlink.net <dblack@candle.superlink.net> writes:

|> The latter would be an error, because
|>
|>   module C::D
|>   end
|>
|> is equivalent to
|>
|>   module C
|>     module D
|>     end
|>   end
|>
|> that causes class/module contradiction.
|
|But why is module C::D equivalent to module/module, more than to
|class/module?  It isn't equivalent in the reference syntax (include
|C::D, etc.), and I think the creation syntax, if any, should be as
|close as possible to the reference syntax.

I can remain "don't care" for referencing, but not for creation.
That's the reason.  If "module C::D" form requires C to be defined
previously, we don't care whether it's a class or module, but I
thought it suppose to define C if it doesn't exist.

|But that's always true of the A::B notation; if it's in a separate
|file, you can't tell what it is.

Again, referencing is different from creation.

|Or if you do this in b.rb instead:
|
|  A.module_eval { module B; end }
|
|the same thing is true: it's an error if you load it first, and you
|can't tell what A is (just from the b.rb source).  But it's legal.

But ugly.  It's the sign of discouragement.  Once

  module A::B
  end

is available, everybody runs for it.

|My feeling is that module A::B should be even *less* smart than you're
|saying :-) To me, "module A::B::C::D" should mean: "Create (or reopen)
|a module called D, with a path through A, B, and C".  An error should
|only happen if that path is impossible (e.g., if B is an integer
|instead of a class or module).

So you require A, B and C to be either class or module predefined.
That's reasonable.  But I feel like it's less useful, but without any
concrete rationale.  Let us discuss.

							matz.