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