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

ProtectAndHide ProtectAndHide at gmail.com
Thu Feb 16 22:25:22 UTC 2023


On Thursday, 16 February 2023 at 21:56:03 UTC, bachmeier wrote:
> On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide 
> wrote:
>
>> Forcing programmers to use a design mechanism rather than a 
>> language mechanism to achieve the above abstraction is wrong. 
>> This seems to be the source of the disagreement, correct?
>
> There's no disagreement. It's you posting the same false claim 
> again and again (presumably because you're hoping it will come 
> up when someone does a search for it, or some similar reason) 
> and others explaining why you're wrong.
>
> If you don't want to use the language, don't use it. You have 
> your subjective preferences. You are unable to muster a good 
> argument in favor of it. There's no reason to (yet again) post 
> the same thing over and over.


also, I noticed that you intentionally? did not respond to the 
facts that I outlined:

ie.

Objects are data abstractions with an interface of named 
operations and a hidden local state. Does anyone disagree with 
this?

D does not have a language mechanism, but rather a design 
mechanism that supports the above.
By that I mean, you cannot use a language 'declaration' mechanism 
to enforce the above, but rather have to revert to a design 
mechanism - putting the class that represents that object into a 
module by itself. Does anyone disagrre with this?

Forcing programmers to use a design mechanism rather than a 
language mechanism to achieve the above abstraction is wrong. 
This seems to be the source of the disagreement, correct?

So some think its fine to force this onto programmers? That is 
essentially your argument... right?

This is about the language. It's not personal. Don't make it 
personal!


More information about the Digitalmars-d-learn mailing list