Scope modules DIP rough messy draft.

[12345swordy]

On Sunday, 28 October 2018 at 12:50:30 UTC, luckoverthere wrote:
> On Saturday, 27 October 2018 at 22:03:12 UTC, 12345swordy wrote:
>>> Separating code into multiple files with modules is also good 
>>> programming practice :).
>> Which sometimes you got break the rules in order to get 
>> something done. Like using goto for instance.
>
> You could say the same thing about your one time scripts. You 
> can break your rule of encapsulation being a good programming 
> practice in order to get your one time script done (into one 
> file). Like these rules don't need to be followed to the 
> letter, nor should they be.
Yet, you have no tools to write multiple modules in a file in D. 
It not a rule but a hard limitation.
> This benefit does not really extend to one time scripts.
That itself is very opinionated and debatable, and the dip itself 
is not about specifically one-time scripts. People keep focusing 
on the tree rather then the overall forest, so I had remove that 
section and plan to do over again by focusing on the one file per 
module limitation and how that should it be a rule of thumb 
rather then a hard limitation.
> If your scripts are getting so large that it does benefit, then 
> they probably shouldn't be one file any longer.
Again debatable, not reason why the DIP exist.

> You can try and argue in the DIP that having a single 
> extra-large file is good practice and is something D should 
> support, but that's honestly an argument you are probably going 
> to fail to convince anyone of.
Which I am not arguing. I am arguing to allow creation of 
multiple modules in single file.
>
> Now you have to consider the complicated situation you are now 
> able to achieve with your new system.
>
> How do you handle multiple modules with the same name. You 
> mention that this is the same:
>
> module A;
>
> public import B;
>
> is the same as:
>
> module A;
>
> module B
> {
>     void foo();
> }
>
> So that means B is not part of A, correct?
No, that is NOT equivalent!

module A;

public import A.B; //This is where you got it wrong.

is the same as:

module A;

module B //This is viewed as A.B or module B part of package A
{
    void foo();
}
>> I can access B without going through A
No you can't. Module B is part of the A package.

> Does the module B in A work with just the separate module B?

Yes, because module B is part of the A package. So it just really 
A.B and B which are completely different.


> module C;
>
> module B
> {
>     void foo();
> }
>
> ///////////////////////////
>
> import A;
> import B;
> import C;
>
> B.foo(); // Which does this call now ?

C.B.foo(); // calls C package
B.foo(): // calls B module

Otherwise the compiler will throw a ambiguity error.