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

[forkit]

On Friday, 3 June 2022 at 10:12:04 UTC, Guillaume Piolat wrote:
> On Friday, 3 June 2022 at 05:58:06 UTC, Mike Parker wrote:
>>
>> No, it's not sad.
>
> +1, not everything has to be decoupled.
> Being in the same file means you want those things to be 
> coupled, and thus you get that.
> I much prefer that to the "friend" thing in C++.

Hey, it's fine that the D module is in effect 'the owner' of the 
representation of a class, rather than the class itself. While 
suprising to some, that's just how it is.

It's not a bad thing. There are benefits in that approach, and I 
am not arguing against that approach.

But in D, if you want to statically enforce class encapsulation, 
the *only* way you can do this, is by putting every every class 
in its own file.

That is what's sad.

> +1, not everything has to be decoupled.
+1 ;-)

> Being in the same file means you want those things to be 
> coupled, and thus you get that.

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.