On Saturday, 27 October 2018 at 13:35:05 UTC, 12345swordy wrote:
> On Saturday, 27 October 2018 at 04:54:30 UTC, Neia Neutuladh wrote:
>
>> Why do one-time scripts need extra tools to help maintainability? A one- time script is not maintained by definition.
> I have wrote scripts before with encapsulation in mind, because it consider to be good programming practice. Even that script is onetime use. It good to reuse code from old code such as scripts for example.

So when you copy and paste, do so by putting it into its own module. If you are just going to copy and paste it into another one time script then it doesn't really make a whole lot of sense. You can still use private and such in your one time script and when you copy and paste it to a larger file with its own modules you will have the encapsulation.

Separating code into multiple files with modules is also good programming practice :). If you are going to day that you can't really pick and choose the ones that only benefit your argument.

On Saturday, 27 October 2018 at 20:34:36 UTC, Jusl wrote:
> So when you copy and paste, do so by putting it into its own module.
...Which you be doing anyways with the feature I presented.
Don't like it? Don't use it. Same reason for goto statements.
> If you are just going to copy and paste it into another one time script then it doesn't really make a whole lot of sense.
Which is your opinion. I have use old code from one time scripts before, and saves me quite amount of time. No need to write multiple files to write a one time script that involves encapsulation. Which again a design decision that I and other programmers can make. People are going to use d language in ways that you may not agree with. You not agreeing with the design decision they make is not an argument against the features themselves.
> You can still use private and such in your one time script and when you copy and paste it to a larger file with its own modules you will have the encapsulation.
Again a mere opinion regarding design decision and not the feature itself.
> 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.
> If you are going to day that you can't really pick and choose the ones that only benefit your argument.
...What?

On Sat, 27 Oct 2018 22:03:12 +0000, 12345swordy wrote:
> Which is your opinion. I have use old code from one time scripts before, and saves me quite amount of time. No need to write multiple files to write a one time script that involves encapsulation.

This sounds like the perfect use case for a personal utility library.

On Saturday, 27 October 2018 at 22:51:15 UTC, Neia Neutuladh wrote:
> This sounds like the perfect use case for a personal utility library.
I consider that solution to be over engineering to me. Regardless I was using C# for creating the one time scripts in the past, not D.

Again it seems like people are missing the forest for the trees by focusing on the examples themselves rather then the underline argument that there are reasonable possible situations that the programmer find it easier to create file to that stores multiple modules then to create every file for every module.

-Alex

On Sat, 27 Oct 2018 23:17:36 +0000, 12345swordy wrote:
> On Saturday, 27 October 2018 at 22:51:15 UTC, Neia Neutuladh wrote:
>> This sounds like the perfect use case for a personal utility library.
> I consider that solution to be over engineering to me. Regardless I was using C# for creating the one time scripts in the past, not D.
> 
> Again it seems like people are missing the forest for the trees by focusing on the examples themselves rather then the underline argument that there are reasonable possible situations that the programmer find it easier to create file to that stores multiple modules then to create every file for every module.

You have a tool in mind to address a narrow set of circumstances. It would be useful. But we do already have tools to address the same circumstances. Not quite as well, but they're already here. And D is already a very complex language with a lot for people to learn, so any new changes have to be pretty valuable to be justified.

The way we justify changes is by looking at examples to see what existing features don't allow or only allow awkwardly, and then comparing with how the proposed change would make them work.

On Saturday, 27 October 2018 at 15:25:10 UTC, 12345swordy wrote:
> On Saturday, 27 October 2018 at 15:13:11 UTC, Neia Neutuladh wrote:
>> DIPs are an area where we don't trust the judgment of the person making the proposal. We need an actual argument instead.
>> A good argument here would be a single D module which is complex enough that encapsulation is necessary and where it's apparent *why* it can't just be broken up into smaller modules.
>
> I had simplify the DIP rationale as it quite apparent that people are missing the forest for the trees by nitpicking the design choice that hypothetical programmer may use in the examples rather then focusing the underlying "one file per module" restriction.
>
> -Alex

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? What benefit does this provide over what you can already do? Who else is even going to be able to access this module? If no one else can access it there's no point in it being a module.

Not even C++ makes this mistake of allowing namespaces in the body of functions. Same thing goes for modules being defined in classes.

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.

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. Encapsulation provides benefits for projects of larger scale, where it is unrealistically possible for someone to know how everything operates, or spending the time to figure out how it works. This benefit does not really extend to one time scripts. If your scripts are getting so large that it does benefit, then they probably shouldn't be one file any longer.

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.

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? So if I do:

import A;

B.foo(); // I can access B without going through A
foo();   // same here

What happens now when you have a separate module with B ?


import A;
import B;


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

Or even worse:

module C;

module B
{
    void foo();
}

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

import A;
import B;
import C;

B.foo(); // Which does this call now ?


These are details you are going to have to iron our, and depending on how you want to implement it, will cause the implementation for the compiler to become extremely complicated (as which is the case with C++ namespaces).

On Sunday, 28 October 2018 at 00:14:05 UTC, Neia Neutuladh wrote:
> On Sat, 27 Oct 2018 23:17:36 +0000, 12345swordy wrote:
>> [...]
>
> You have a tool in mind to address a narrow set of circumstances. It would be useful. But we do already have tools to address the same circumstances. Not quite as well, but they're already here. And D is already a very complex language with a lot for people to learn, so any new changes have to be pretty valuable to be justified.
>
> The way we justify changes is by looking at examples to see what existing features don't allow or only allow awkwardly, and then comparing with how the proposed change would make them work.

Yup. I noticed that I didn't clarify in regards to the public import and plan old import, I need to fix that.

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.

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

> Not even C++ makes this mistake of allowing namespaces in the body of functions!
No one wants c++ namespaces here, as we have modules!
> Same thing goes for modules being defined in classes.
We already allow nested functions and nested classes, why not nested modules as well?
> 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!