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

[unprotected-entity]

On Saturday, 27 October 2018 at 02:49:00 UTC, 12345swordy wrote:
>
> D IS an object-oriented language as much as c++, just not a 
> pure one.

Most do not really understand the use of that term 
'object-oriented'.

In fact, an object can best be defined as: "a software machine 
allowing programs to access and modify a collection of data".

That means D is object-oriented - it's just that the module is 
THE object in D).

That translates to D treating the 'class' as a subordinate object 
(under the control of the module) - which is very different to 
C++, Java and C#.


> "Have a short learning curve for programmers comfortable with 
> programming in C, C++ or Java."
> Gee, I wonder why?

I do not see large numbers of C++/Java/C# programmers, switching 
over to D anytime soon - particulary if they have a fondness 
towards object-oriented programming using classes.

But...I really *do* sympathise with your argument.. but, knowing 
what I know, you're better off using your mental energy on some 
other issue ;-)


> You didn't read the dip that I wrote did you? Nowhere in the 
> dip did I change the concept of the modular unit. I just remove 
> the one module per file Limination. That is it.

I actually found the dip draft confusing. After reading the 
justification at the start, for what was going to be proposed, 
and then reading what was actually proposed .. well.. to me, they 
don't seem to be entirely in sync with each other.

In any case, given the justification, I would replace the 
proposed solution to say .."Go use another language that 
(already) does what you want it to do".

If you have a fondness for classes, you will likely benefit from 
using another language ;-)