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

[forkit]

On Tuesday, 7 June 2022 at 10:13:35 UTC, Ola Fosheim Grøstad 
wrote:
>
> This works perfectly well in practice. I've never had a problem 
> with it. The reason is that encapsulation is «just a reminder» 
> and that works well unless you insist on being stupid. Stronger 
> encapsulation is only essential if you redesign larger programs 
> or have teams with disloyal programmers who are taking 
> shortcuts.

I disagree with your assertions here. I don't think you've fully 
grasped the benefits of encapsulation in terms of decomoposition.

In any case, you simply cannot encapsulate the semantics of an 
object (within a class definition) in D, since code surrounding 
it can get at any part of its specification. But wait. There's 
more. D 'insists' on not giving you the means to protect that 
encapsulation. D just does not have the language construct to do 
that - intentionaly, by design even!

Putting the class in its own module does not change this fact - 
i.e. you still need to ensure there is no other code surrounding 
it (including unit test), for it to have a kind of pseudo 
encapsulation.

The simple fact is, that a class in D is a weak type, since 
violations of its contract from other code in the module, cannot 
be detected during compilation.

Instead, it deliberately, intentionally, proudly, leaves this 
important aspect in software development to the programmer(s).