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.

Reply via email to