Wed Oct 17 - Avoiding Code Smells by Walter Bright

[FooledDonor]

On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh 
wrote:
> On Sat, 03 Nov 2018 04:50:52 +0000, unprotected-entity wrote:
>> (q1) Why is it, that people who use D, object *so much* to the 
>> idea of
>> allowing (at the choice of the programmer) for a type to have 
>> it's own
>> private state *within* a module (so that its private state is 
>> respected
>> by other code also within that module)?
>
> We object because the people complaining can't point at a use 
> case that seems reasonable. If you provided real-world 
> examples, we'd consider them.
>
> We are further disinclined to engage with you as a collaborator 
> because you're insulting us and ignoring a lot of our responses 
> to you.

This reasoning is meaningless: one must not prove the obvious.
During the writing of a complex module, it happened to me many 
times to desire what unprotected-entity asks.

And if the validity of a person's reasoning is a function of his 
way of expressing them, well ... do not pose to software 
engineers at least


>
>> Or you ask it another way:
>> 
>> (q2)Why must a type within a module *always* have its private 
>> state
>> exposed to other code within the module? (the key word here, 
>> being
>> 'always').
>
> Because that is both simple and flexible. Swift forsakes 
> simplicity in favor of high granularity, and it's exhausting 
> just reading its protection modifier list.
>
>> (q3) Should a language intentionally set out to prevent a 
>> programmer
>> from making that choice?
>
> You're mischaracterizing the situation to make your preferred 
> feature look like the default. That's the opposite of how 
> language design works. Nothing is there by default. You add 
> things as necessary to get a language that's good enough.

What he asks is reasonable and useful, and help in a myriad of 
cases. I can not even see a disadvantage in the introduction of a 
true private attribute.

What you ask is reasonable and useful, and help in a myriad of 
cases. I can not even see a disadvantage in the introduction of a 
true private attribute.

But already, it seems that nobody still really understands how to 
use the DIP1000 in the practicality of its code, 
"const-immutable" is a failure, five hundred pages of reasoning 
about "shared", entire sections of language abandoned halfway 
.... a poor man is asked to bring evidence that the water is wet 
.... geezzzz