On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:
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.
Class level private, which can ensure that there will never be
any leakage and there will be no encapsulation misuse,
At the module level, this is unavoidable!
And there are closely related classes, which should be placed in
a module.
