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

[Stanislav Blinov]

On Friday, 26 October 2018 at 21:16:54 UTC, 12345swordy wrote:
> On Friday, 26 October 2018 at 20:52:38 UTC, Stanislav Blinov 
> wrote:

> What is that all about!? Are you type of guy who like get into 
> fights?

I'm not the guy who stomped in here demanding answers from a 
language author regarding false assumptions.

>>> Class private member variables are behaving like they 
>>> protected class protected when creating derived class in the 
>>> same module.
>>
>> Which is a problem because?..

> It's a problem as we have the protected keyword already! There 
> is no reason for private to act it's protected in the same 
> module!

"protected" exists solely for classes, not modules.

> If you want child to inherent your private member variables 
> then used protected.

The word is "access", not "inherit". But indeed, if you want 
child to have access to parent's state inaccessible to external 
code, you should use 'protected'. That's exactly how you can 
allow other people to access some of the sate even when they're 
inheriting in another module.

> Otherwise private should mean that belongs to class A and only 
> to class A. If you wanted your child class to inherent private 
> member variables only in a module then we need a new access 
> attribute to avoid unwanted pitfuls.

It feels like you don't understand how inheritance works. A 
derived class *does* inherit *all* of the parent's guts 
irrespective of where they're defined relative to each other, or 
what visibility attributes they have. It's just that some of the 
guts may not be accessible to the derived class. Parent's private 
state doesn't magically disappear from the derived class' bits.

>>>> There's no contradiction. Within a module, you have access 
>>>> to everything.
>>> This is about inheritance not encapsulation. You shouldn't be 
>>> accessing doors when they shouldn't exist in the first place.
>>
>> So... use the language as intended
> That is a huge moot point itself that should belong it own 
> thread.

How so? You're arguing that the spec is wrong when it clearly 
works as it says in this particular case.

>> and don't put things that  absolutely must not access private 
>> data into the same module.
> I repeat:
> This is about inheritance not encapsulation. You shouldn't be
> accessing doors when they shouldn't exist in the first place.

This *is* about encapsulation, which in itself is about 
visibility. "private" is strong encapsulation, "public" is weak 
encapsulation, "protected" is the middle ground. But a unit of 
encapsulation in D is a module, not a class.

> You are debunking a straw man.

Eh?

>> Class is within a module. It's members are within a module. 
>> Ergo, they're accessible even when private. Again, there's no 
>> contradiction at all.

> Again you are debunking a straw man.

No. I'm explaining to you that your understanding of the spec is 
incorrect.

>> So? As long as the "team" uses the same language, all it's 
>> members should understand what "private" means *in that 
>> language*.
>>
>>>>There's absolutely no need for artificial restrictions.
>>> Nonsense, @safe and @nogc are artificial restrictions. Code 
>>> discipline is good behavior, even for yourself.
>>
>> 1) @safe and @nogc have nothing to do with visibility
> You didn't say visibility, you said "artificial restrictions"

What was it that you said about strawmen? Your topic is about 
"private". "private" is a visibility attribute. Disallowing 
access to your own data within your own module, to code that you 
yourself are writing is unnecessary; it is an artificial 
restriction that serves no purpose.

>> Yep, which is exactly why the language lets you do whatever 
>> you want with symbols inside a module.
> Really? Then why I can't get rid private member variables that 
> class B inherent from class A that is marked "private".
> Do I have to mark them delete every time I inherent?

"private" doesn't get rid of anything. It simply disallows access 
outside of module. At least in D that's what it does. Again, 
perhaps there's something wrong with your understanding of 
inheritance.

> Tone of voice do not transfer over the internet.

Which is why you should've thought twice before demanding answers.