On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
1st - D has broken the concept of class encapsulation, simply for convenience at the module level. Not good in my opinion.
No, it hasn't broken encapsulation. Encapsulation is at the module level. A class or struct and any supporting functions can be included in a single module and the private API is encapsulated from the outside world.
2nd - C++/C#/Java programmers will come to D, use the same syntax, but get very different semantics. Not good in my opinion. (i.e. I only realised private was not private, by accident).
D is not C++, C#, or Java. C++ uses friend to get around the issue. Java has no solution. I don't know about C#.
D has made many good design decisions. I do not see this as one of them.
I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module".
In Java, it's recommended to manipulate private member variables through their accessors even in methods of the same class. I've always found that extreme. If you need to make a breaking change to the member variable, you already have access to all of the method internals anyway. Yes, there's room for error if you forget to make a change, but with all the support in modern IDEs and editors for find/replace, it's a simple matter to handle it all at once. And in the standard edit-compile-run cycle, any breakage is discovered right away, not weeks down the road in the field.
The same applies here. Encapsulation simply isn't broken by this feature.
