Non-ugly ways to implement a 'static' class or namespace?
ProtectAndHide
ProtectAndHide at gmail.com
Thu Feb 16 20:56:00 UTC 2023
On Thursday, 16 February 2023 at 13:39:13 UTC, H. S. Teoh wrote:
> On Thu, Feb 16, 2023 at 08:51:39AM +0000, FeepingCreature via
> Digitalmars-d-learn wrote: [...]
>> Springboarding off this post:
>>
>> This thread is vastly dominated by some people who care very
>> much about this issue. Comparatively, for instance, I care
>> very little because I think D already does it right.
>>
>> But then the thread will look unbalanced. This is a
>> fundamental design flaw in forum software.
>>
>> So let me just say: I think D does it right. D does not have
>> class encapsulation; it has module encapsulation. This is by
>> design, and the design is good.
>
> +1, this issue is wayyy overblown by a vocal minority. D's
> design diverges from other languages, but that in itself does
> not make it a bad design. In the context of D it actually
> makes sense. Saying that D's design is bad because language X
> does it differently is logically fallacious (X is good, Y is
> not X, therefore Y is bad).
>
>
> T
It's really the vocal majority that makes this issue overblown.
One person saying they don't like something...dozens deciding to
weigh in and say how wrong he is. So whose doing the overblowing?
The 'fact' of the matter is, that the vast majority of
programmers in the most major languages have the capacity to
explicately declare hidden data associated with their
user-defined type (class, struct..whatever).
Both the module type, and the class type need this capability.
One without the other leads to the kind of errors I made when I
first started writing classes in D (which of course I now longer
use D for).
So for the D's 'majority' to flood this thread saying 'no we're
right and you're wrong' and all the other major languages in the
world are wrong, as are their designers, and all the programmers
using them are blind, and don't really need that capability... I
mean really? Are we meant to take that seriously?
D was clearly created by procedural programmers for procedural
programmers.
And again, a language that deliberately forces an important
design decision onto programmers (one-user-defined-type per
module just to protect its hidden data), is wrong. D people
saying its fine, are wrong. It's just wrong.
If you think its not wrong, you are wrong.
A user-defined type where the programmer cannot explicately
declare protected hidden data, is wrong.
If you think its not wrong, you are wrong.
More information about the Digitalmars-d-learn
mailing list