Non-ugly ways to implement a 'static' class or namespace?
ProtectAndHide
ProtectAndHide at gmail.com
Wed Feb 15 09:57:56 UTC 2023
On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote:
> On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker
> wrote:
>
>> I meant to say, it "wouldn't add more".
>
>
> 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`.
In a module that contains a class, and other code as well
(perhaps other tightly coupled classes), you can know **nothing**
at all about that type (or any other class) without knowing
**everything** else in the module. If one understands this, then
one understands the problem here ;-)
.. btw. other code.. includes unitests as well.
The solution that D provides, is not a solution. It's a design
constraint being forced on programmers. Anyone that argues
otherwise, is speaking out of their ...
More information about the Digitalmars-d-learn
mailing list