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