Why do private member variables behaved like protected in the same module when creating deriving class?

[unprotected-entity]

On Friday, 26 October 2018 at 22:42:42 UTC, 12345swordy wrote:
> You are right, I am better off continuing writing the dip about 
> nested modules then argue ad nauseam about this.

Actually, if the programming language does correctly, what it 
defines as correct (as defined by it's specification), then it is 
correct (for that programming language).

"Correctness is the prime quality" - Bertrand Myers.

Now...in an 'object-oriented' language, classes are the only 
'modules'.

That means, the class (the module) is the encapsulating unit by 
which you construct your program.

D is not an object-oriented langauges - although it does have 
classes.

Classes in D are NOT the modular units by which you are expected 
to construct your program; rather the module unit in D, is .. the 
'module'.

All decisions about classes in D, seem to derive from that 
concept.

If you want the 'information hiding' capabilities that 
object-oriented languages offer to classes, then use an 
object-oriented language.

Many come to D from object-oriented languages, and expect classes 
to operate in the same way in D, as they did in those languages. 
It aint going to happen - in D. Why? Because the designers of D 
expect you to use the module, not the class, as the encapsulating 
unit for constructing your program.

Really, you are better off using a language that does what *you 
want* it to do, instead of getting the language to change it's 
concept of the modular unit.

If you persist in trying to change D's concept of what the 
modular unit is, then you will only get the type of responses 
that you are already starting to get, and, you persist - it will 
likely get worse (based on the history around similiar 
discussions of D's implementation of classes).

Move on, and use another language that doesn't redefine the 
traditional concept of a class, like D does - that is my advice 
;-)