Scope modules DIP rough messy draft.

[12345swordy]

On Sunday, 28 October 2018 at 23:47:21 UTC, luckoverthere wrote:

> Probably for the better, importing with classes and functions 
> is actually useful. Being able to define a module in those 
> scopes provides nothing.
No, it provides encapsulation. It no different the defining it in 
another file and only use it at that particular function/class.


> Ok, why not give some now?
Look up the limitations of nested functions.

> Yes that's the point, which benefits classes and functions, but 
> the point of a module is provide a grouping.
Modules are the unit of encapsulation. It does not solely exist 
for grouping.

> If that grouping is inaccessible to anyone else then there 
> really isn't any benefit.
> The class and function act as a grouping in this case.
> Having nested functions and classes is useful though.

You are contradicting yourself here. Nested class/functions are 
inaccessible to anyone else. Ergo they aren't really benefit to 
them according to your logic.


> Missing the point, even C++ with all its warts is smart enough 
> not to implement nested namespaces in classes and functions 
> (namespaces being C++'s way of grouping code vs D's modules).
C++ namespaces and D modules are not remotely the same thing.
https://stackoverflow.com/questions/6326805/why-using-namespace-x-is-not-allowed-inside-class-struct-level

> Because they provide little benefit, the functional purpose of 
> a module is to group classes and functions.
Modules are the unit of encapsulation. It does not solely exist 
for grouping.

> Nested modules do not.

Creating classes and putting them in their own modules in the 
same file under the same package isn't a benefit!?
The nested module exist to get rid of one module per file 
restriction and to provide easy encapsulation.

Regardless you not the person that the DIP need to be convinced. 
It's andrei and walter.