`restricted` member variables

[Mike Parker]

On Thursday, 23 June 2022 at 03:55:00 UTC, forkit wrote:

>
> Or is this all new to D users?

I was a Java programmer before I was a D programmer. I understand 
all of the OOP principles you've been bringing up in this 
discussion, as I'm sure everyone else does.

What I'm arguing is that those principles still hold in D. The 
difference between D and Java (or similar) is that in D, the 
boundary is at the module level, not the class level. Everything 
in the module is part of the private API. We've just expanded the 
definition of private API from "inside the class" to inside the 
module. Your types are still as strong, still as encapsulated, 
via the public API (outside of the module).

In Java, anything that shouldn't touch the private API of a class 
shouldn't be part of that class. In D, anything that shouldn't 
touch the private API of a class shouldn't be in the same module 
as that class. How are the two concepts any different?

This is what you've got to show. What is the *practical* problem 
that private-to-the-module causes that wouldn't be true if we had 
private-to-the-class (i.e., what can go wrong with the module as 
part of the private API that wouldn't go wrong if the same thing 
were done inside the class).

Yes, there's a problem in that invariants and mutex locks can be 
bypassed, but that's not a problem with the private API. The 
private API is allowed to touch that stuff. It's a problem 
because it violates the public API, i.e., external calls to 
module functions bypass the invariant and the mutex lock. That's 
a bug that can be fixed without a new protection attribute.

Arguments that encapsulation is broken in D because of 
private-to-the-module are purely ideological without a concrete 
example of a problem a new protection attribute would prevent. 
Yes, it's true that the class boundary is violated in the module. 
But because the module is part of the private API, that doesn't 
matter one bit.