Rethink OOP access permissions

[NotYouAgain]

On Saturday, 27 April 2024 at 09:25:13 UTC, Daniel N wrote:
> This is an alternative to "private(this)".
> ..

private(this) is trying a very specific problem - that can be 
demonstrated in the contrived code further below.

That is, anyone other than the author will not know whether a 
mistake is in this code.

Maybe even the author will miss it ;-(

If there is a mistake, the compiler will be of no help here.

But what is certain, most programmers who look at this code will 
not know whether a mistake is being made or not. And it precisely 
because oop in D is really mop (module-oriented-programming).

D does however, provide a means to illude oo programmers into 
thinking they're doing oop, if they put each class in its own 
module, with no other code whatsoever. This makes the type a 
strong type, with compiler enforced guarantees, and it gives you 
the illusion that you're doing oop.

But there is no more easier to grasp, easier to implement 
solution here, other than private(this).

D claims to support oop, but when you really look into it, it's 
really mop, with the silly burden it places on you, that you have 
to put a class in its own module if your want oop like guarantees.

How would your alterative compare to private(this) in the code 
below?

class ClassWithPrivateField
{
   private int privateField; // actually, I really wanted to do 
'private(this)' here.
   this() { this.privateField = 42;  }
}

class Subclass : ClassWithPrivateField
{
   private int subPrivateField;

   this()
   {
     this.subPrivateField = 23;
     this.privateField = 52; // mmm .. this may or may not be a 
mistake.
                             // without private(this) you cannot 
know.
                             // you could use convention, but we 
all know
                             // how well that scales ;-)
   }
}