Very hacky solution to class private members

[bauss]

On Thursday, 9 June 2022 at 10:03:02 UTC, Dom Disc wrote:
> On Thursday, 9 June 2022 at 09:22:52 UTC, forkit wrote:
>> On Thursday, 9 June 2022 at 08:44:50 UTC, bauss wrote:
>>>
>>
>> honestly. how is it, that a programming language can enable 
>> you to do all this amazing stuff, like that, and yet not 
>> provide an access control option (let alone an enforceable 
>> one) at the class level.
>
> I still don't get why class level encapsulation should be any 
> better than module level encapsulation.
> You need it to prevent some function from accidentally use 
> things it shouldn't use, yes? Because if you _want_ to 
> circumvent the privacy, there are always ways to do that.
> But what about all the member-functions of a class, that also 
> should not have access to some variables? (Because most of the 
> time, private members should only be accessed by a few members 
> that are designed to work with them). There neither private or 
> hidden on whatever level can help you.
> So, whatever you do, the only way to review a class is to 
> simply check that all usages of a private variable are 
> justified at the place where it is used. And that becomes 
> easier if you have to check only one file, but if it is only 
> used in a part of a file doesn't reduce the effort the 
> slightest bit. Zero. No effect.
> So I just can't understand why you insist on class level 
> encapsulation. It brings no benefit at all (at least regarding 
> the effort for reviews).

Might as well just make everything public then, right? Why stop 
there. Removing private, protected, package etc. is the way to go 
then?

I mean, you can review them all yourself and make sure they're 
not used incorrectly.

The flawed mentality in your answer is that you forget that the 
point of it all is to cut down the amount of code you have to 
review.

There's no reason to do the analysis yourself if the compiler can 
do it for you in 99% of the cases.