On Friday, 26 October 2018 at 21:05:56 UTC, Steven Schveighoffer wrote:
> On 10/26/18 3:28 PM, 12345swordy wrote:
>> On Friday, 26 October 2018 at 18:57:00 UTC, Neia Neutuladh wrote:
>>> On Fri, 26 Oct 2018 18:16:38 +0000, 12345swordy wrote:
>>>> [...]
>>>
>>> D's `private` within a module is identical to Java's `private` within a class and its nested classes. The following is valid Java:
>>>
>>> [...]
>> 
>> Again I am referring to classes in the module not the module itself.
>
> Classes in the module are in the module. So any classes in the module *are* the module itself.
>
> What it seems like you are saying is that you want non-derivatives to still be able to access private variables, but derivative classes are forbidden? Nothing personal, but this really doesn't make a lot of sense. I feel like maybe there is a misunderstanding.

There is a misunderstanding! I am asking why the child class have the parent class private member variables in the first place!!!
Do I need to write a DIP for you guys to understand what the hell I am talking about!?

On Friday, 26 October 2018 at 21:16:54 UTC, 12345swordy wrote:
> 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!
> If you want child to inherent your private member variables then used protected.
> 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.

`protected` isn't the same. `protected` will allow derived classes to access a member, even if they are not in the same module. `private` can only be accessed within a single module.

On Friday, 26 October 2018 at 21:40:10 UTC, Laurent Tréguier wrote:
> On Friday, 26 October 2018 at 21:16:54 UTC, 12345swordy wrote:
>> 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!
>> If you want child to inherent your private member variables then used protected.
>> 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.
>
> `protected` isn't the same. `protected` will allow derived classes to access a member, even if they are not in the same module. `private` can only be accessed within a single module.

...Did you read the other post that I made before you made that reply?

I swear I am repeating myself ad nauseam.

On Friday, 26 October 2018 at 21:42:37 UTC, 12345swordy wrote:
> ...Did you read the other post that I made before you made that reply?
>
> I swear I am repeating myself ad nauseam.

You simply seemed to be implying that private had the same effect as protected, which isn't the case.
And yes, you are repeating yourself ad nauseam, since this is, I believe, your 3rd thread about this whole thing about the private keyword.

On Friday, 26 October 2018 at 21:46:27 UTC, Laurent Tréguier wrote:
> On Friday, 26 October 2018 at 21:42:37 UTC, 12345swordy wrote:
>> ...Did you read the other post that I made before you made that reply?
>>
>> I swear I am repeating myself ad nauseam.
>
> You simply seemed to be implying that private had the same effect as protected, which isn't the case.
> And yes, you are repeating yourself ad nauseam, since this is, I believe, your 3rd thread about this whole thing about the private keyword.

*this is actually only the second, apologies.

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.

On Friday, 26 October 2018 at 21:46:27 UTC, Laurent Tréguier wrote:
> On Friday, 26 October 2018 at 21:42:37 UTC, 12345swordy wrote:
>> ...Did you read the other post that I made before you made that reply?
>>
>> I swear I am repeating myself ad nauseam.
>
> You simply seemed to be implying that private had the same effect as protected, which isn't the case.
... How can I make my self any more clear here!? When I say y behaves like x it I don't means y is exactly the x! Nor does it imply that!

On Friday, 26 October 2018 at 22:01:42 UTC, 12345swordy wrote:
> On Friday, 26 October 2018 at 21:46:27 UTC, Laurent Tréguier wrote:
>> On Friday, 26 October 2018 at 21:42:37 UTC, 12345swordy wrote:
>>> ...Did you read the other post that I made before you made that reply?
>>>
>>> I swear I am repeating myself ad nauseam.
>>
>> You simply seemed to be implying that private had the same effect as protected, which isn't the case.
> ... How can I make my self any more clear here!? When I say y behaves like x it I don't means y is exactly the x! Nor does it imply that!

Then I don't know why the fact that we have protected means that the way private behaves is wrong.

Anyway, I regret even partaking in this thread and I'll stop here, because from what I see:
You would like private to be visible only in the class it was declared in, and nothing else. Instead it's visible from everything in the module (including, indeed, the derived classes). As others have pointed out, it's precisely said in the docs that private is about modules and not classes.

It's not going to change as it would break code; if you have an idea of how to improve this, write a DIP like the one you started with nested modules, and present it here on the forum if you want people's opinion.

On Friday, 26 October 2018 at 22:00:21 UTC, Stanislav Blinov wrote:
> On Friday, 26 October 2018 at 21:16:54 UTC, 12345swordy wrote:
>> [...]
>
>> [...]
>
> I'm not the guy who stomped in here demanding answers from a language author regarding false assumptions.

"who stomped in here". That is your imagination.
>>> [...]
>
>> [...]

> "protected" exists solely for classes, not modules.
It like you not even trying to understand what I am saying here.
>> [...]
>
> The word is "access", not "inherit".
I know what I meant when I use the word "inherit". Don't play coy with me.
> 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.

*sigh*
>
>> [...]
>
> 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.
>
>> [...]
>
> How so?
What does "use the language as intended" mean anyway?

>> [...]
>
> 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 addressing a straw man still.
>> [...]
>
> Eh?
>
>>> [...]
>
>> [...]
>
> No. I'm explaining to you that your understanding of the spec is incorrect.
>
Or poor reading compensation.
>> [...]
>
> What was it that you said about strawmen?
You literally use the words "artificial restrictions"!
>
>> [...]
>
> "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.


>> [...]

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

No, that is you failing to follow the conversation. I am done.

On Friday, 26 October 2018 at 22:23:04 UTC, Laurent Tréguier wrote:
> On Friday, 26 October 2018 at 22:01:42 UTC, 12345swordy wrote:
>> [...]
>
> Then I don't know why the fact that we have protected means that the way private behaves is wrong.
>
> Anyway, I regret even partaking in this thread and I'll stop here, because from what I see:
> You would like private to be visible only in the class it was declared in, and nothing else. Instead it's visible from everything in the module (including, indeed, the derived classes). As others have pointed out, it's precisely said in the docs that private is about modules and not classes.
>
> It's not going to change as it would break code; if you have an idea of how to improve this, write a DIP like the one you started with nested modules, and present it here on the forum if you want people's opinion.

You are right, I am better off continuing writing the dip about nested modules then argue ad nauseam about this.