Using closure in function scope to make "real" private class members

[forkit]

On Friday, 3 June 2022 at 11:50:22 UTC, Mike Parker wrote:
> On Friday, 3 June 2022 at 10:37:28 UTC, forkit wrote:
>
>>
>> Not necessarily. The overall goal should be encapsulation 
>> (hence in D, the one class per module recommendation). But the 
>> goal of encapsulation is to manage complexity and support 
>> local reasoning. It's not an excuse to force programmers to 
>> put each class in its own module, in order to statically 
>> enforce its represenation.
>
> And in D you encapsulate at the module level. We don't need 
> another keyword for more fine-grained encapsulation, because we 
> already have a solution in the form of the package module.

That's fine, if a module that contains a class, is nice and 
short, and only contains code that directly acts on that class, 
and no other code, whatsoever.

Otherwise the encapsulation 'could' be broken (i.e. mutations 
maybe occuring outside of your encapsulated representation), and 
you won't know unless you know ALL the code in that module (as it 
cannot be enforced statically by the compiler). It's up to the 
human to verify the correctness.

To just say the programmer owns the module, and therefore 
everything will be fine.. is naive.

Practically speaking, anyone that uses a class in D, must be put 
it in its own module - no exceptions.