Preparing for the New DIP Process

[FairEnough]

On Saturday, 27 January 2024 at 01:57:01 UTC, Elias (0xEAB) wrote:
> On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote:
>> That can end up to be a lot of files needing to be managed, 
>> simply to control the escape of state into a module.
>
> In case you’re worried about the clarity in your editor’s file 
> list (or in similar tools), try packagizing your modules; that 
> should lead to folders that are easily collapsible.
>
> In case you’re worried about running out of inodes on ext4 
> filesystems, maybe give XFS a try.

No, not really worried about running out of inodes ;-)

My interests are in types that are correct (in both design and 
use) and enforcable (at least to a reasonable extent).

Without private(this) you cannot determine the intent of that 
types use by other code in the module. And you certainly cannot 
enforce it. This is true for all other code, including code for 
unitttests.

Without private(this), you *always* leak *all* of the types state 
into the rest of the module. Hence the workaround of putting 
every type in its own module, and every unittest making use of 
that type in a separate module to that type.

Otherwise, leaky state will inevitably bite you (unless you're 
one of those programmers that never make mistakes).