On Tuesday, 13 March 2018 at 06:58:08 UTC, psychoticRabbit wrote:
What you're saying, is in D, class encapsulation is really
'module' encapsulation.
I get it. Fine. It's an intersting design decision.
"Enapsulation" in D means the same as it does in every other
language -- hidden from the outside.
The purpose of encapsulation is to prevent client code from
breaking when an internal API changes. That's exactly the level
of encapsulation that D's private provides. Making private
restrict access to the class would be like other languages, sure,
but then it becomes over restrictive.
But, in doing that, D has shifted the boundary of class
encapsulation, to a boundary that is outside the class.
Nope. It's still hidden from the outside world. No one can read
or write private class members *from the external API*.
To me, that sounds like D has broken class encapsulation. I
don't know how else one could describe it.
I continue to think, that class encapsulation is sacred, a well
defined, well understood, concept that has been around for a
very long time.
Only if you view encapsulation as something other than "hidden
from the outside world".
private could have still meant private, and surely someone
could have come up with a different access modifier to mean
'private at module level'.
Was that too hard the language designers?
Was it not hard, but just to complex to implement?
I don't get it.
Any new keywords, or reuse of existing keywords, does make the
language more complex. Everything that is added must have a
reason. Private is module level because friend is so common in
C++, i.e. people find it useful and it would be great to support
something similar in D. Making modules the lowest level of
encapsulation does that without the need for an extra keyword for
friends while still maintaining a strict border between external
and internal APIs. Moreover, it restricts friends to the same
module, easing the maintenance burden and decreasing the chance
of error. It was a great decision.
