On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:
...
I suspect the proportion of users that really care about
explicit class privacy and find the workaround of putting a
class that needs such privacy into a separate file untenable,
will remain the same.
Jordan
Well D already has class privacy. Would be absurd if it didn't.
So this is not about class privacy per se, nor is it about OOP.
It's about whether D should provide an *option* for class privacy
within a module, so that the programmer can use it when it is
appropriate (e.g. there is other code in the module as well,
perhaps even just a unittest, and the programmer wants the
compiler to enforce type safe use of that type within that
unittest).
But still none of what you said addresses the questions I put
forward. Answers to those questions will form the basis for a
need (or not), for private(this).
(Q1) Are there any circumstances where a class type might need to
retain control over its state from other code within the same
module (including unittest code)?
(Q2) What problems could potentially occur when a class types
state is always leaked into the module.
If your answer to Q1 is no, then there is nothing more to say.
If your answer to Q1 is yes, but in this case just put the type
in its own module, then you've not really answered the question,
since there would be no other code in the module.
If your answer to Q2 is none, then there is nothing more to say.
If your answer to Q2 identifies one or potential problems, you
have an immediate type safety concern that needs to be addressed,
somehow. There is no language feature to help you deal with that
problem (i.e have the compiler enforce your design). You simply
have to avoid putting any other code in the same module (this
includes your unittest code).
So D's approach to answering these two questions, is you should
prevent the circumstance from ever arising by constraining your
design to one type per module, and the unittest for that type in
its own separate module as well. That will be acceptable to some,
and not others.
It also raises a final question of whether that is all the D
programming language should ever provide to the programmer - a
way to avoid these situations by constraining your design.
If you answer yes, there is obviously nothing more to discuss.
If you answer no, then what can be done about it?
As I've mentioned, I think Swift got the balance right.
