Non-ugly ways to implement a 'static' class or namespace?
ProtectAndHide at gmail.com
Wed Feb 15 10:40:23 UTC 2023
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:
> 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.
The convincing arguement (convincing to me anyway) was made when
I came to D, programmed a class, and put a unittest in the same
module, and accidently referenced hidden data of my class in my
unittest. This result in a bug. It was when i was tracking down
the source of this bug, that I discovered that private is not
private at all (inside the module).
If there is a cycle continuing, it's because your solution to a
'real' problem (read above again please), is to force an
unreasonable design constraint onto the programmer.
This includes being forced to put your unittest in its own module
as well (for reasons demonstrated above).
It should be up to the programmer to decide what types should go
into their module: Not the language! You think the language has
this right to force such a constraint onto the programmer, I do
not. That really is the basis for the disagreement here.
I want fewer modules, each containing tighly couple types.
You want more modules, each containing one single type.
I want unittest in the same module as my type.
You want me to have them in their own module as well.
No. I cannot accept this as a reasonable solution.
More information about the Digitalmars-d-learn