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

Hipreme msnmancini at hotmail.com
Thu Feb 9 23:05:35 UTC 2023


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


More information about the Digitalmars-d-learn mailing list