`restricted` member variables

[deadalnix]

On Wednesday, 22 June 2022 at 08:16:26 UTC, Ola Fosheim Grøstad 
wrote:
> It is useful when building your model. That is too obvious a 
> point to argue: Start out by making everything maximally 
> constrained, then loosen up (reluctantly) when you have no 
> other option. The resulting model will be much better than if 
> you just can change things from the outside. The reason for 
> this is that good encapsulated code will produce a higher line 
> count, and most programmers aim for a low line count 
> (subconsciously or deliberately).
>

I don't think this is obvious at all. Assuming you and I were 
extremely intelligent, we wouldn't need any of that? We could 
keep the whole state of the whole program in our mind and 
manipulate it with ease.

But we aren't. We are just dumb monkeys. So we build abstractions 
under which we hide part of the complexity of the world we are 
dealing with and present it through a simplified API. This allow 
our monkey brain to do more because we can temporarily forget 
many aspect of the problem at hand.

But this comes at a cost. Typically, component A wasn't available 
from B, so the team in charge of B ends up making a different one 
that works how so slightly differently rather than depend on A 
(mind you, they may even now know that A exist at all, or have 
any sensible way to discover that fact), and now the end result 
is worse because there are two thing that do A in a slightly 
different way. Casey Muratori demonstrate that effect using the 
volume slider in windows here: 
https://www.youtube.com/watch?v=5IUj1EZwpJY&t=2054s (see 
timestamp, but the whole presentation is very much worth a watch).

So what is the barrier we put in place for our monkey brain when 
we use private? We state that the private thing is an 
implementation detail, and that whoever is using our interface 
shouldn't have to know about it. It leaves space in their brain 
for something else, which is more important for them to solve the 
problem at hand - at least, this is the assumption we make.

But here, we see the whole bizarre of the current argument: if I 
want to isolate the user of my code from having to know of the 
implementation detail of my interface, then it logically follows 
that they don't belong in the same module, as the module is the 
unit of abstraction at which implementation happens.

The ask is fundamentally inconsistent in its motivations, and 
this is why the only argument we have for it so far all come in 
the form of "the holy scripture says so".