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
