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

[ProtectAndHide]

On Wednesday, 15 February 2023 at 07:23:39 UTC, thebluepandabear 
wrote:
> On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker 
> wrote:
>> On Wednesday, 15 February 2023 at 01:16:00 UTC, 
>> thebluepandabear wrote:
>>
>>>
>>> I think what you could say is that D lacks _encapsulation_ 
>>> which is also an OOP concept. So D is partially OOP but not 
>>> fully OOP due to there being no encapsulation in the language.
>>
>> D does not lack encapsulation, it's just that the unit of 
>> encapsulation is the module. Everything private in a module is 
>> encapsulated from the perspective of the public API.
>>
>> If you really want to prevent anything inside a module from 
>> accessing the private parts of a class, you can put the class 
>> in its own module.
>>
>> Must we continue beating this horse?
>
> Why is the unit of encapsulation the module though? Makes no 
> sense.


It does make sense. But not if the language also provides 
user-defined types. That is explained in the Stroustup paper I 
cited.

That is, a language that provides modules as well as user-defined 
types, should provided encapsulation for both. D does that, but 
for user-defined types it doesn't in the context of other code in 
the same module as that type. That is why in D you are 'forced' 
to put that type in its own module 'just' to encapsulate it from 
other code that would have otherwise been in the same module.

No. It makes no sense. A user-defined type should be able to 
protect hidden data from other code within the same module. That 
really doesn't sound that extreme to me ;-)