Scope modules DIP rough messy draft.

[luckoverthere]

On Monday, 29 October 2018 at 00:45:47 UTC, 12345swordy wrote:
> 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.

How is encapsulation going to be beneficial in a situation where 
the class can only be used from inside that function?


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

That wasn't the question. If you don't have an answer then that's 
fine, say you don't though.

>> 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.

In this case the function/class is the unit of encapsulation, you 
can't access nested functions/class unless they are returned.

>> 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.

That's the point of them, they aren't accessible to anyone, 
that's the encapsulation. They can still be returned as well if 
wanted. You would be adding a grouping on top of a grouping. The 
function grouping is much more restrictive than a module 
grouping, not even other functions in same module can access 
nested functions/classes (unless it is used as the returning 
type).

>> 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

Lol you had to google that and it's a link to a stackoverflow 
question no less.

They serve the same purpose, to group code and provide a means to 
avoid name collisions between differing objects. They can also be 
used to ensure functions are encapsulated to a specific source 
unit using anonymous namespaces.

You can also research C++ proposal for modules, which is 
implement in a similar fashion to what you are suggestion. 
Allowing multiple modules in one file. Their implementation 
however, does not allow modules to be defined in a function or 
class.

>> 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.

And you already have that encapsulation because it is nested. In 
this case the function and class are the units of encapsulation.

>> 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.

Seems your misunderstanding here, nested modules, as in nested in 
a function/class.

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

Your right, it'll be much harder to convince andrei and walter 
than it would be to convince me.