Scope modules DIP rough messy draft.

Neia Neutuladh neia at ikeran.org
Sat Oct 27 15:13:11 UTC 2018


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.


More information about the Digitalmars-d mailing list