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.
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.
la..de.da..de.dah...
really just sounds like more obfuscatation to me...
As I said, I don't think the 'please no, don't do it, it'll just
make our syntax too complex' position can be taken seriously. And
in any case, and how many time do I have to tell you this
(turning your phrase to me, back on you), that this is NOT a
request for change. This is just a discussion about what benefit
it might provide, if the programmer had the choice to have
declare private state for a type, and have the compiler enforce
that design choice, by preventing other code within the module to
have direct access to that types private state.
Now..go and read that last paragraph again...
no more obfuscation...please.
