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

[forkit]

On Friday, 3 June 2022 at 05:58:06 UTC, Mike Parker wrote:
>
> ...
> Any argument about encapsulation here is purely ideological. If 
> you have access to the source file, you have access to the 
> private members, period.
> ...

No. Not really. It's more than ideological.

As long as the module contains one, and only one class, and only 
contains code that manipulates that one class, then encapsulation 
is maintained within that module - regardless of where in the 
module that code is.

The problem, is that a module can contain all sorts of code, and 
any of the code can alter the way you think that class might 
operate (i.e. the interface of that class cannot be relied upon, 
witin a module, that contains any code unrelated to that class.

For the person who has access to the module, this 'might' not be 
a problem (as long as they extra careful not to let code in the 
module alter the properties of the class, where the class 
definition did not account for that.

The other problem, where code in the module may exist, that 
doesn't relate directly to the manipulation of the class, is that 
someone reading the code in that module cannot be assured the 
interface of that class is being used correctly, unless they 
audit ALL the code in that module. I'll say that again - they 
need to audit ALL the code in that module.

For these reasons, the programmer must ensure that every class is 
contained in it's owm module, and that any code in that module 
directly relates to the properties/functionality of that class. 
While this might be considered best practice, an option to make a 
property of class truly private within the module, would provide 
some flexibiltiy to this requirement.