https://github.com/12345swordy/DIPs/blob/Encapsulation/DIPs/DIPxxxx.md
Yea, yea, I know it format wise it a giant mess, but I got start somewhere don't I?

On Saturday, 27 October 2018 at 00:20:33 UTC, 12345swordy wrote:
> https://github.com/12345swordy/DIPs/blob/Encapsulation/DIPs/DIPxxxx.md
> Yea, yea, I know it format wise it a giant mess, but I got start somewhere don't I?

I don't know the rationale to me seems weak:

> Using D as a scripting language becomes more complicated to use for one time scripts as you have to deal with multiple files if you design the classes/structs to be encapsulated by themselves. Where it would be idealy for the scripter to just to handle one file instead of mutiple files.

Why do "one time scripts" need this feature? They will be used one time, no? Why do you need to follow encapsulation for a script you will run once? It will be small enough that you  can read all the code and know what it does.

> Porting from C++ to D involves refactoring, when the programmer should be avoiding refactoring as much as possible during the porting process, as refactoring during the port process can lead to unintended bugs.

D is less restrictive than C++, because it is less restrictive you don't need to refactor. There also is no equivalent "friend" feature in D. Since you are just copying and pasting code, for the most part, where are you going to accidentally call a private function you weren't calling before in C++ that you are now going to call in D.

> Rapidly creating a program that involves multiple modules requires multiple files for it, which can cause the slow down the coding process, most noticeably in coding competition.

Again encapsulation is to aid in creation and maintenance of large code bases for longevity sake. Why would you be worried about encapsulation in a coding competition, most likely the fastest code aren't going to be following any sort of best practice as the fastest code will probably be using some crazy hacks anyways.

> It sometimes it easier to put every module in a single file for a simple small program.

If it is a simple small program, then why require private at all? It's small enough that knowing what all the code does by a single person is reasonable, let alone that it doesnt do anything complicated either.


On a side note, "function" is a keyword in D. Not sure if that was an intentional choice or not, but seems odd with your examples and the syntax highlighting.

On Saturday, 27 October 2018 at 02:07:56 UTC, luckoverthere wrote:
> On a side note, "function" is a keyword in D. Not sure if that was an intentional choice or not, but seems odd with your examples and the syntax highlighting.
That was an unintentional mistake I made.
Regardless this is nowhere near the final draft, as I have to take account of templates and string mixins. Which is not going to be trivial. My general philosophy is that if you only use module a for module b then use module scoping.
Same rational for local functions.

On Saturday, 27 October 2018 at 02:07:56 UTC, luckoverthere wrote:

> Why do "one time scripts" need this feature?
To avoid writing multiple files.


> D is less restrictive than C++, because it is less restrictive you don't need to refactor. There also is no equivalent "friend" feature in D. Since you are just copying and pasting code, for the most part, where are you going to accidentally call a private function you weren't calling before in C++ that you are now going to call in D.

It does not necessarily involve friend functions. If your c++ code rely on the class is a unit of encapsulation as part of your design, then switching to d breaks that design as the module itself is the unit of encapsulation. You have to refactor your code by putting each class in its own file.

>> Rapidly creating a program that involves multiple modules requires multiple files for it, which can cause the slow down the coding process, most noticeably in coding competition.

> Why would you be worried about encapsulation in a coding competition, most likely the fastest code aren't going to be following any sort of best practice as the fastest code will probably be using some crazy hacks anyways.
That is more of a a broad objection to encapsulation in coding competition then the feature presented at the dip itself.

> If it is a simple small program, then why require private at all?
That the design that the programmer decides on.

On Sat, 27 Oct 2018 04:13:40 +0000, 12345swordy wrote:
> On Saturday, 27 October 2018 at 02:07:56 UTC, luckoverthere wrote:
>> Why do "one time scripts" need this feature?
> To avoid writing multiple files.

Why do one-time scripts need extra tools to help maintainability? A one- time script is not maintained by definition.

Is it that great a hardship to include multiple files when it's getting hard to maintain your project as a single file?

> It does not necessarily involve friend functions. If your c++ code rely on the class is a unit of encapsulation as part of your design, then switching to d breaks that design as the module itself is the unit of encapsulation. You have to refactor your code by putting each class in its own file.

If you wish to port a project from C++ to D, you should expect to have to refactor it after if you want a maintainable codebase. That's not surprising in the slightest.

>> If it is a simple small program, then why require private at all?
> That the design that the programmer decides on.

So the motivation for choosing this sort of design is...because you chose this sort of design? Like, you decided on a constraint that your entire program had to fit in one file, and you find it difficult to maintain your program as one file because the unit of encapsulation doesn't match your design, but you made a decision, and by Aten you're sticking with it.

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.

> Is it that great a hardship to include multiple files when it's getting hard to maintain your project as a single file?

Ease of use comes to play here. If I had to create every file every time to ensure encapsulation in other languages I would go mad.

>
> If you wish to port a project from C++ to D, you should expect to have to refactor it after if you want a maintainable codebase. That's not surprising in the slightest.

You shouldn't have to refactor during porting process in order to ensure encapsulation. This feature minimize the refactoring.

>>> If it is a simple small program, then why require private at all?
>> That the design that the programmer decides on.
>
> So the motivation for choosing this sort of design is...because you chose this sort of design?
I can't explain every design decision that you find it questionable. That is not the goal of the DIP here. You just have to trust the programmer judgement.

On Saturday, 27 October 2018 at 00:20:33 UTC, 12345swordy wrote:
> https://github.com/12345swordy/DIPs/blob/Encapsulation/DIPs/DIPxxxx.md
> Yea, yea, I know it format wise it a giant mess, but I got start somewhere don't I?

Ok I have simply rationale by stating that one module per file should be a guideline/rule of thumb rather then a hard limit. There are cases/situations where it easier to put multiple modules in a single file.

On Sat, 27 Oct 2018 13:35:05 +0000, 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.

If you're reusing code, wouldn't you tend to pull it out into a library? You can use `dub build --single` to build a single-file dub package, using a comment in lieu of dub.sdl, and you can use `dub add-local` to expose that utility library on your local system.

>> Is it that great a hardship to include multiple files when it's getting hard to maintain your project as a single file?
> 
> Ease of use comes to play here. If I had to create every file every time to ensure encapsulation in other languages I would go mad.

So using Java, the most popular programming language in the world, would cause you to go mad?

I think that might indicate that D isn't the problem.

>> If you wish to port a project from C++ to D, you should expect to have to refactor it after if you want a maintainable codebase. That's not surprising in the slightest.
> 
> You shouldn't have to refactor during porting process in order to ensure encapsulation. This feature minimize the refactoring.

On the other hand, if you're porting from Java, D's encapsulation fits better.

D's encapsulation can't model C++'s exactly. This goes to how you decide how to arrange your source code into files, and C++ is much freer about this than almost any other language. But for some simple cases, it would ease porting.

>>>> If it is a simple small program, then why require private at all?
>>> That the design that the programmer decides on.
>>
>> So the motivation for choosing this sort of design is...because you chose this sort of design?
> I can't explain every design decision that you find it questionable. That is not the goal of the DIP here. You just have to trust the programmer judgement.

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.

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

On Saturday, 27 October 2018 at 15:13:11 UTC, Neia Neutuladh wrote:
> So using Java, the most popular programming language in the world, would cause you to go mad?

I am actually working on some Java right now and it totally drives me nuts. The directory structures are so deep and there are so many little files.

I finally have a handle on what it is doing though, yay!



As to this DIP, meh, I could quibble with the specifics, but I have kinda wanted multiple modules per file before myself, though it isn't a big deal (indeed, library packaging is another alternative). It just seems like an arbitrary limitation not to allow another module declaration there. In C, you can cat *.c > combined.c and still build it (well, generally), but in D that always creates errors.

Multiple smaller modules do the encapsulation and can help with code bloat, though compiler implementation improvements are helping with that too. But recall that is why the package.d thing was added.

Again, no big deal, but I could see myself sometimes using it.