On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote:
What if two classes in the module that are several meters apart
make `mistakes` that change the privite variable of `another
class`?
No one can guarantee that after `a few months`, even if you are
the author, you will not make mistakes, so as to misuse private
variable, while `class level` private can be completely avoided
it!
There is no maintainability, because two `out-of-class`
functions may quietly change your private `variables`.
I referenced that in my post. The exact same problem exists
*inside* the class when your class file is very long. You can
easily manipulate the private member even when it's only supposed
to be accessed by a specific function. A common recommendation in
Java used to be (and probably still is) to always accessing
private members by their setters even inside the class. And after
all these years they haven't had a need to lock down
single-method access to private members. It's the *exact* same
thing in D: the private implementation is in the source file. The
fact that the source file represents a module rather than a
single class is irrelevant.
We keep repeating the same arguments over and over and over again
on this. I still haven't seen any convincing argument for
changing things when it's already possible to do what you want to
do. I repeat for the umpteenth time: if you care so much about
who can touch your private parts, then put your classes and
structs in their own modules and use D's package facilities to
provide the public interface you want.
