On 10/26/18 12:27 PM, 12345swordy wrote:
> On Friday, 26 October 2018 at 18:45:32 UTC, Stanislav Blinov wrote:
>> On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
>>> Mike Parker told me that this is intentional and not a bug.
>>
>> It's not a bug.
> Is this really necessarily?
> 
>> Why "however"?
> 
> Class private member variables are behaving like they protected class protected when creating derived class in the same module.

[snip]

Whether this loophole is desirable and useful is a matter of opinion. It certainly is deliberate, though. I believe it may have been inspired by C++'s "friend" declarations. The comparison may help with understanding why D does it this way: https://dlang.org/articles/cpptod.html#friends

In my opinion it reflects D's ethos of keeping the common practice safe but attempting to always allow an escape hatch.

On Friday, 26 October 2018 at 19:45:48 UTC, David Gileadi wrote:
> On 10/26/18 12:27 PM, 12345swordy wrote:
>> On Friday, 26 October 2018 at 18:45:32 UTC, Stanislav Blinov wrote:
>>> On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
>>>> Mike Parker told me that this is intentional and not a bug.
>>>
>>> It's not a bug.
>> Is this really necessarily?
>> 
>>> Why "however"?
>> 
>> Class private member variables are behaving like they protected class protected when creating derived class in the same module.
>
> [snip]
>
> Whether this loophole is desirable and useful is a matter of opinion.
Yes! Someone knows what I am talking about! I don't want to break other people code that depends on this loophole. I just want a way to close this loophole, by using the final keyword.

> It certainly is deliberate, though. I believe it may have been inspired by C++'s "friend" declarations. The comparison may help with understanding why D does it this way: https://dlang.org/articles/cpptod.html#friends
>
> In my opinion it reflects D's ethos of keeping the common practice safe but attempting to always allow an escape hatch.
If it deliberate, then it needs to be documented.

On Friday, 26 October 2018 at 19:55:08 UTC, 12345swordy wrote:
> On Friday, 26 October 2018 at 19:45:48 UTC, David Gileadi wrote:
>> On 10/26/18 12:27 PM, 12345swordy wrote:
>>> On Friday, 26 October 2018 at 18:45:32 UTC, Stanislav Blinov wrote:
>>>> On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
>>>>> Mike Parker told me that this is intentional and not a bug.
[clip]
>>
>> Whether this loophole is desirable and useful is a matter of opinion.
> Yes! Someone knows what I am talking about! I don't want to break other people code that depends on this loophole. I just want a way to close this loophole, by using the final keyword.

But this loophole doesn't really provide you any mechanism to
breaking other people's code that you don't already have.  You write
the module, and if you want to be extra safe you can follow the
convention of implementing each class in its own module.

[clip]
>>
>> In my opinion it reflects D's ethos of keeping the common practice safe but attempting to always allow an escape hatch.
> If it deliberate, then it needs to be documented.

But it is:
https://dlang.org/spec/attribute.html#visibility_attributes

On Fri, 26 Oct 2018 19:28:43 +0000, 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.

Perhaps you could show an example of what you want to forbid? I think that would be the most effective way for you to communicate what you mean.

On Friday, 26 October 2018 at 19:27:11 UTC, 12345swordy wrote:
> On Friday, 26 October 2018 at 18:45:32 UTC, Stanislav Blinov wrote:
>> On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
>>> Mike Parker told me that this is intentional and not a bug.
>>
>> It's not a bug.
> Is this really necessarily?

Yes. It's so that you don't solely blame Mike for your misunderstanding of the language. Now you can blame me if you want.

>> Why "however"?
>
> Class private member variables are behaving like they protected class protected when creating derived class in the same module.

Which is a problem because?..

>> 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 and don't put things that absolutely must not access private data into the same module. Doors expunged.

>>> Why private member variables behave like protected member variables in the same module?
>> Because according to the spec, "Symbols with private visibility can only be accessed from within the same module."
> Was referring to class member variables not the module member variables.

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.

>> It's *your* module.
> There are cases where is not necessarily "my" module but rather it is the "team" module.

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.
2) Exactly my point.

>> To keep your desk drawer tidy you, well, keep it tidy, not mess it up and throw away the key.

> How I organized my desk drawer is up to me though.

Yep, which is exactly why the language lets you do whatever you want with symbols inside a module.

>>> Can you explain your thought process when it comes to this design decision Walter Bright?
>> I'm sure Walter should be honored to be graced with such an eloquent inquiry.
> Is that sarcasm?

No, no, I really think Walter owes you an explanation as to why your assumptions about the language are faulty.

...Of course it was sarcasm. Sigh.

On Friday, 26 October 2018 at 20:22:14 UTC, Craig Dillabaugh wrote:

> But this loophole doesn't really provide you any mechanism to
> breaking other people's code that you don't already have.
I don't want class B to inherent class A private variables in the same module! If I want to do that I use the protected keyword in class A, that why the keyword
"protected" exist in the first place! It occupied unwanted space, and creates unwanted complicity!

>  You write
> the module, and if you want to be extra safe you can follow the
> convention of implementing each class in its own module.
>
I am not talking about encapsulation, I am talking about inheritance.
To put it simply, I am not asking who can open the door or not, I am asking that if the door should exist in the first place.
> [clip]
>>>
>>> In my opinion it reflects D's ethos of keeping the common practice safe but attempting to always allow an escape hatch.
>> If it deliberate, then it needs to be documented.
>
> But it is:
> https://dlang.org/spec/attribute.html#visibility_attributes
If it is, then I wouldn't be having this conversation. I didn't know that derived class inherent private variables members of the parent class in the same module.

On Friday, October 26, 2018 1:55:08 PM MDT 12345swordy via Digitalmars-d wrote:
> On Friday, 26 October 2018 at 19:45:48 UTC, David Gileadi wrote:
> > It certainly is deliberate, though. I believe it may have been inspired by C++'s "friend" declarations. The comparison may help with understanding why D does it this way: https://dlang.org/articles/cpptod.html#friends
> >
> > In my opinion it reflects D's ethos of keeping the common practice safe but attempting to always allow an escape hatch.
>
> If it deliberate, then it needs to be documented.

What are you asking for exactly? The documentation documents exactly what the behavior is:

https://dlang.org/spec/attribute.html#visibility_attributes

"2. Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."

Are you looking for the documentation to explain why there is a "loophole" to private that allows other symbols within a module to access private members of a class of struct? As far as D is concerned, private doesn't even really _have_ anything to do with classes or structs. It's one of the access level attributes that you can apply to members of a class or struct (just like you can use it on module-level symbols), but it's private to the module, not the class or struct. It's understandable that you'd think that it was private to the class or struct, since other languages do that, but nowhere in the documentation does D ever say anything of the sort. It quite clearly states that it's private to the module. So, from D's perspective, there is no loophole. The whole idea that private is private to the class or struct has nothing to do with D. The only reason that you think that there's a loophole is because of preconceptions about private that you have from experience with other languages.

The spec _could_ compare D's version of private to that of other languages in order to show why that particular design decision was made, but that's not the sort of thing that's usually in the spec. In general, the spec specifies what the language is but doesn't go into detail with every little decision about _why_ it is the way it is. Maybe it should in some cases. I don't know. Our spec isn't very good overall, because Walter isn't good at writing specs (and has said as much). I'd have to go study something like the C or C++ spec to see how a spec really _should_ be written. Ours can't seem to decide whether it's a tutorial or a proper spec. But what the documentation says is correct about the behavior. The whole idea that private would be anything else is just based on assumptions made after having used other languages that have private and classes.

- Jonathan M Davis

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.

Note that the lack of ability to encapsulate data in classes or structs within a module has been discussed here a lot. It's not going to change, however, as it comes down to a deliberate choice between encapsulation and ease of implementation.

-Steve

On Friday, 26 October 2018 at 20:52:38 UTC, Stanislav Blinov wrote:
> On Friday, 26 October 2018 at 19:27:11 UTC, 12345swordy wrote:
>> On Friday, 26 October 2018 at 18:45:32 UTC, Stanislav Blinov wrote:
>>> On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
>>>> Mike Parker told me that this is intentional and not a bug.
>>>
>>> It's not a bug.
>> Is this really necessarily?
>
> Yes. It's so that you don't solely blame Mike for your misunderstanding of the language. Now you can blame me if you want.
>
What is that all about!? Are you type of guy who like get into fights?
>>> Why "however"?
>>
>> 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!
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.

>>> 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.
> 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.

You are debunking a straw man.


> 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.


> 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"

>>> To keep your desk drawer tidy you, well, keep it tidy, not mess it up and throw away the key.
>
>> How I organized my desk drawer is up to me though.
>
> 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?

>
> No, no, I really think Walter owes you an explanation as to why your assumptions about the language are faulty.
>
> ...Of course it was sarcasm. Sigh.
Tone of voice do not transfer over the internet.

On Friday, 26 October 2018 at 20:55:00 UTC, Jonathan M Davis wrote:
> On Friday, October 26, 2018 1:55:08 PM MDT 12345swordy via Digitalmars-d wrote:
>> On Friday, 26 October 2018 at 19:45:48 UTC, David Gileadi wrote:
>> > [...]
>>
>> If it deliberate, then it needs to be documented.
>
> What are you asking for exactly? The documentation documents exactly what the behavior is:
>
> https://dlang.org/spec/attribute.html#visibility_attributes
>
> "2. Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."
>
> Are you looking for the documentation to explain why there is a "loophole" to private that allows other symbols within a module to access private members of a class of struct?

No I am asking why class B inherent the private variables of class A that is marked private, when we have the protected keyword.

I don't know how else I can I make this any clearer.