On Sunday, 28 October 2018 at 12:50:30 UTC, luckoverthere wrote:
> 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.


Also don't give out suggestions that you think are futile. That is just being condescending.

On Sunday, 28 October 2018 at 16:16:01 UTC, 12345swordy wrote:
> On Sunday, 28 October 2018 at 12:32:57 UTC, luckoverthere wrote:
>>
>> The way it is implemented is promoting even poorer practices.
>>
>>> void function()
>>> {
>>>   module A
>>>   {
>>>     ...
>>>   } }
>>>
>>> Which is equalivent to:
>>> 
>>> void function()
>>> {
>>>   import A;
>>> }
>>
>> Why would you want to define a module within a function?
> Not allowing it, will result the "if you can import it you can build it" rule being inconsistent. It no different then creating a separate file that is only called by one function from another file.

Probably for the better, importing with classes and functions is actually useful. Being able to define a module in those scopes provides nothing.

>> What benefit does this provide over what you can already do?
> Lots surprisingly. Don't worry, I will address the benefits that arise from this in the dip in the future.

Ok, why not give some now?

>> Who else is even going to be able to access this module?
> The same reason for nested functions and nested classes, no one, that is the whole point! If you want it to be shared then don't put it there in the first place.

Yes that's the point, which benefits classes and functions, but the point of a module is provide a 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.

>> If no one else can access it there's no point in it being a module.
> You can argue against nested function and nested class using that logic!

Having nested functions and classes is useful though. Having a nested module within a pseudo module (the class/function) isn't really beneficial.

>> Not even C++ makes this mistake of allowing namespaces in the body of functions!
> No one wants c++ namespaces here, as we have modules!

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

>> Same thing goes for modules being defined in classes.
> We already allow nested functions and nested classes, why not nested modules as well?

Because they provide little benefit, the functional purpose of a module is to group classes and functions. Nested classes and functions already have a grouping, the class/function they are nested in. We don't need further groupings in these cases.

>> Just cause you can import a module in these places, does not mean you should be able to define an entire module in the same place.
> Nonsense, D pride itself as a practical language. That is why D have gotos, which if you don't like it, don't use it!

You keep bringing up gotos, but aside from that rule you seem to like to follow. Gotos actually have their uses. Nested modules do not. Over filling a language with features also isn't a good thing and makes is less practical as a whole. Having too many features, especially ones that add little value just complicates the language. Making it harder to read and write for everyone. Not just the people that choose to use one of the features everyone else avoids.

On Sunday, 28 October 2018 at 17:50:14 UTC, 12345swordy wrote:
> On Sunday, 28 October 2018 at 12:50:30 UTC, luckoverthere wrote:
>> 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.
>
>
> Also don't give out suggestions that you think are futile. That is just being condescending.

I wasn't giving it as a suggestion, you already had added that bit to your DIP, though you didn't really expand on it. And I was merely giving my opinion of it. It's a good thing you removed it.

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.

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.

// A.d /////////////////////////////////////////////////////////

module A;

public import A.B; // What happens here now ?

module B
{
   void foo();
}

// B.d ////////////////////////////////////////////////////////

module A.B;

void foo();

//////////////////////////////////////////////////////


Then consider code like this, which will compile fine, using the file with module A.B

import A.B;

A.B.foo();


But then when if you decide to change it and import A instead:


import A;

A.B.foo();


You are calling a different function from the same module name. As there are actually two difference instances of the module, module A.B can mean two different things depending on the circumstance.

On Monday, 29 October 2018 at 01:37:07 UTC, luckoverthere wrote:
>
> // A.d /////////////////////////////////////////////////////////
>
> module A;
>
> public import A.B; // What happens here now ?
>
> module B
> {
>    void foo();
> }

what you are doing is the equivalent of this:

module A.B;
public import A.B;


> You are calling a different function from the same module name.

If you have more then one module with the same name with conflicting definitions then the compiler will give you an ambiguity error. You can encounter that same problem without this Dip. Put two modules named A in the same folder with different functions definitions and try to call it from module B.

-Alex

On Monday, 29 October 2018 at 01:17:06 UTC, luckoverthere wrote:
> How is encapsulation going to be beneficial in a situation where the class can only be used from inside that function?
That because, nested classes are NOT encapsulated in the function!
The module itself is the encapsulation unit, not the class. (I learn that the hard way)

int func()
{
    class Inner
    {
        private int x;
    }
    Inner ex = new Inner();
    ex.x = 1;
   globalvar = ex.x;
   return ex.x;
}

This compiles btw.

> That wasn't the question.
You ask "what are the benefits", I had give you the answer: The Dip will address the limitations of nested functions and provide a solution for them via nested modules.

> In this case the function/class is the unit of encapsulation
No, they are NOT! The module IS unit of encapsulation. Period. Global variables can accessing anything provided that they are in the same module.

> That's the point of them, they aren't accessible to anyone, that's the encapsulation.
If they are in the same module, yes you can! If you try to create a global pointer outside the function that points to local private variable inside the function in the same module you are technically accessing it! You just got a dangling pointer after the function is called.

> Lol you had to google that and it's a link to a stackoverflow question no less.
You are creating a false equivalence by comparing D modules with C++ namespace.
You can import modules in a class in D, you can't import a namespace in class in C++. Ergo your comparison fall flat.

> Their implementation however, does not allow modules to be defined in a function or class.

Irrelevant.

> And you already have that encapsulation because it is nested.

Nested classes/functions are not encapsulated. The module itself is the unit of encapsulation.


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

Nested classes/functions are not encapsulated. The module itself is the unit of encapsulation.

> Your right, it'll be much harder to convince andrei and walter than it would be to convince me.
It seems that way if you oppose it on ideological grounds.
Regardless, apparently I need to dedicate a section that is called "Only the module itself is the unit of encapsulation" in the DIP.

On Monday, 29 October 2018 at 14:45:19 UTC, 12345swordy wrote:
> On Monday, 29 October 2018 at 01:17:06 UTC, luckoverthere wrote:

> int func()
> {
>     class Inner
>     {
>         private int x;
>     }
>     Inner ex = new Inner();
>     ex.x = 1;
>    globalvar = ex.x;
>    return ex.x;
> }
>
> This compiles btw.

So? You, the programmer, are breaking encapsulation here by accessing 'private' member. You wrote that code, you better know what 'x' is. Your argument seems to be based on an assumption that you don't have to know. But you do, otherwise you shouldn't be writing code.

>> That wasn't the question.
> You ask "what are the benefits", I had give you the answer: The Dip will address the limitations of nested functions and provide a solution for them via nested modules.

That'd be interesting to see. Why didn't you put those supposed limitations in there to begin with? I.e. what's the purpose of this "messy draft"?

>> In this case the function/class is the unit of encapsulation
> No, they are NOT! The module IS unit of encapsulation. Period. Global variables can accessing anything provided that they are in the same module.

Global variables aren't accessing anything. You (the programmer) are, by assigning values to them.

>> That's the point of them, they aren't accessible to anyone, that's the encapsulation.
> If they are in the same module, yes you can! If you try to create a global pointer outside the function that points to local private variable inside the function in the same module you are technically accessing it! You just got a dangling pointer after the function is called.

That's not an issue with encapsulation at all. That's a lifetime issue.

```
int* global;

void main() @safe {
    int x;
    global = &x;
}

$ dmd -dip1000 test.d
test.d(5): Error: address of variable x assigned to global with longer lifetime
```

> Nested classes/functions are not encapsulated. The module itself is the unit of encapsulation.

You're confusing encapsulation and scopes now:

void main() {
    void bar() {}
}

void foo() {
    main.bar(); // Error: no property bar for type void
}

On Monday, 29 October 2018 at 15:00:07 UTC, Stanislav Blinov wrote:

> So? You, the programmer, are breaking encapsulation here by accessing 'private' member.
There is no encapsulation break, as it located in the same module. The encapsulation that you speak of is human enforced.

> That'd be interesting to see. Why didn't you put those supposed limitations in there to begin with? I.e. what's the purpose of this "messy draft"?
To get feedback. Which allows me to spot things that need revisiting or need better explaining. This isn't the final draft. Not by a long shot.


> Global variables aren't accessing anything. You (the programmer) are, by assigning values to them.
That counter point doesn't make any sense. You act like that I am arguing that they are intelligent or something.


> That's not an issue with encapsulation at all. That's a lifetime issue.
Not my point. The point is that the compiler won't complain that you are getting the local variable in the function from outside the function, irregardless that you set it to private or not and will compile just as fine.


>> Nested classes/functions are not encapsulated. The module itself is the unit of encapsulation.
>
> You're confusing encapsulation and scopes now:
*shrugs*
 The other user treat them as one as the same.