Non-ugly ways to implement a 'static' class or namespace?

[ProtectAndHide]

On Thursday, 9 February 2023 at 23:05:35 UTC, Hipreme wrote:
> On Thursday, 9 February 2023 at 22:34:29 UTC, ProtectAndHide 
> wrote:
>> On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli 
>> wrote:
>>> On 2/8/23 04:07, zjh wrote:
>>>
>>> > Last time, someone proposed to add `private` like `C++'s`,
>>>
>>> We've discussed the 'private' topic very many times already. 
>>> C++'s private necessitate the 'friend' keyword, which comes 
>>> with it's own problems.
>>>
>>> Besides, D has zero problems with its private implementation 
>>> in the sense that there has been zero bugs related to it 
>>> being that way. Given the number of individuals who bring 
>>> this topic up over and over up is so few that I don't think 
>>> there is a common problem.
>>>
>>> Do you have actual bugs related to this? "Wanting" the 
>>> inclusion of a feature is sufficient.
>>>
>>> In contrast, I use D every day and love its relaxed attitude 
>>> towards private.
>>>
>>> > and then it
>>> > was the same,they are always unwilling to add facilities
>>> useful
>>>
>>> That is not correct. The truth is, nobody is jumping to 
>>> implementations just because some people think they are 
>>> useful. There are always valid reasons for including a 
>>> feature or not.
>>>
>>> Ali
>>
>> You mentioned previously that D implements various things in 
>> unprincipled ways.
>>
>> I guess, if one wants to use D, one has to be comfortable with 
>> this.
>>
>> But using a relaxed attitude towards the implementation of 
>> such a common and important abstraction, that in turn allows 
>> me to so easily shoot myself in the foot, is not really an 
>> attractive feature .. to me ;-)
>>
>> btw. When a newbie to D raises ideas, suggestions, etc... and 
>> you counter them with (in essence) 'we don't need that in D, 
>> but go write a dip if you think we do' attitude, is a real 
>> turn off.
>
>
>
>
> Most of the time, when people use "private", they are actually 
> shooting their users which can't even extend their class. I 
> rarely see code which people use "protected" instead and I find 
> that pretty lacking. One thing is hiding memory allocation 
> details on your class, other thing is hiding a property which 
> could and should be controlled when extended in a class.
>
> To be fair I'm more often than not against private variables. 
> Most of the time it only caused me headaches because there was 
> a lot of unimplemented features and I could not simply fork the 
> project. This is not only in D. I got that in Java, Haxe, C#. 
> Thankfully those languages has ways to simply ignore the 
> private attribute, which can't be done in D.
>
> Anyway, I'm not against static classes and I don't think they 
> would bring any inherent problems, they should not cause 
> regression and they should be easy to implement as the compiler 
> already has the tools for it

Glad to hear someone say they're not 'against' something ;-)

btw. The Swift programming language is superior to D with regards 
to the notion of type privacy.

That is, Swift has fileprivate (which provides **the exact** same 
flexibility of D's private), but Swift (unlike D), *does* allow 
the programmer to choose to have aspects of their type private to 
that type. To something similar to Swift private in D, the 
programmer is **required** to have that type - and nothing else, 
in a module. That then places an important design decision in the 
hands of the langauge, rather than the programmer.

It's unlikely this aspect of Swift is in any way 'unprincipled', 
but more likely, a very well thought out decision to give 
programmers control of their design.

So uising a term someone else mentioned in this thread, the 
programmer is 'free' to make their own choices around type 
privacy in Swift, but not in D :-(