From: Gavin Sinclair <gsinclair@...>
Date: 2003-02-19T08:28:13+09:00
Subject: Re: module This::Encompassing::That

On Wednesday, February 19, 2003, 12:52:44 AM, dblack wrote:

> Hi --

> On Tue, 18 Feb 2003, Gavin Sinclair wrote:

>> I like the idea of autovivification within certain rules.
>>
>> class A
>> end
>>
>> module A::B
>> end                      # error

> In this case, it's not autoviv., because A already exists, so it's an
> explicit creation of B.

> But still, why would the above be an error?  Why not equivalent to:

>   class A
>     module B
>     end
>   end

Well, you could do that if you like.

>> The rule is that the Xi in
>>   module X1::X2::...::Xn
>> must all be either:
>>  - modules (not classes); or

> Why not classes?

I was over-zealously aiming for simplicity.

>>  - non-existent (so an empty module can be created)

> But it could be an empty Class -- meaning, if X2 (or whatever)
> doesn't exist yet, there's no reason to favor the idea that
> it's supposed to be a Module rather than a Class.  There's just
> no way to know.

The idea of the "module" keyword is to create modules :)

This entire proposal - autovivification or otherwise - is just syntax
sugar.  It meets a common need: to define methods within a nested
module (that already exists) or to create a new nested module (i.e.
only one module is vivified).

Given that, it's probably best to drop the autovivification idea, and
only allow that the entire path is unambiguous, save for the creation
of a new module.

  module A
  end

  module A::B::C
  end                    # error

  module A::B
  end

> [...]

Gavin