how to make private class member private

Mike Parker aldacron at gmail.com
Tue Mar 13 06:03:11 UTC 2018


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.


More information about the Digitalmars-d-learn mailing list