I cannot get my head around, why private is not private, in D.

How do I make a private member, private?

-----
module test;

import std.stdio;

void main()
{
    myClass c = new myClass();
    c.myPrivateClassMember= "wtf";
    writeln(c.myPrivateClassMember);
}

class myClass
{
    private string myPrivateClassMember; // private does not mean private anymore??
}

------

Visibility modifiers in D are for the module, not class or struct.

This is very useful to be able to access internal stuff outside of the abstraction and modify it sanely. While also keeping others at bay.

On Tuesday, March 13, 2018 01:12:15 psychoticRabbit via Digitalmars-d-learn wrote:
> I cannot get my head around, why private is not private, in D.
>
> How do I make a private member, private?
>
> -----
> module test;
>
> import std.stdio;
>
> void main()
> {
>      myClass c = new myClass();
>      c.myPrivateClassMember= "wtf";
>      writeln(c.myPrivateClassMember);
> }
>
> class myClass
> {
>      private string myPrivateClassMember; // private does not mean
> private anymore??
> }
>
> ------

private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members.

- Jonathan M Davis

On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote:
>
> private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members.
>
> - Jonathan M Davis

Mmm.. I don't think I like it.

I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation.

No. I don't like it at all.

On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote:
>
> Mmm.. I don't think I like it.
>
> I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation.
>
> No. I don't like it at all.

If you have access to the module source, you have access to the source of types inside it. Making the module the lowest level of encapsulation makes sense from that perspective.

psychoticRabbit wrote:

> On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote:
>>
>> private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members.
>>
>> - Jonathan M Davis
>
> Mmm.. I don't think I like it.
>
> I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation.
>
> No. I don't like it at all.

just stop thinking in C/C++ "#include" terms. there, you have no other ways to restrict data access, so they were forced to make it broken, and then introduce "friends" just to workaround the fact that there are no modules in C++.

instead, start thinking with modules in mind. module is THE unit of incapsulation. there is nothing wrong in isolating class or two in a module. then, to make imports manageable, either create a package of that, or just a dummy module that does `public import xxx;` for everything.

On Tuesday, 13 March 2018 at 02:24:38 UTC, Mike Parker wrote:
> On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote:
>>
>> Mmm.. I don't think I like it.
>>
>> I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation.
>>
>> No. I don't like it at all.
>
> If you have access to the module source, you have access to the source of types inside it. Making the module the lowest level of encapsulation makes sense from that perspective.

There are two problems I see:

1st - D has broken the concept of class encapsulation, simply for convenience at the module level. Not good in my opinion.

2nd - C++/C#/Java programmers will come to D, use the same syntax, but get very different semantics. Not good in my opinion. (i.e. I only realised private was not private, by accident).

D has made many good design decisions. I do not see this as one of them.

psychoticRabbit wrote:

> There are two problems I see:
1) it is not how C++ done it.
2) it is not how C++ done it.

and you're completely right: it is not how C++ done it.

On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote:
> psychoticRabbit wrote:
>
>> There are two problems I see:
> 1) it is not how C++ done it.
> 2) it is not how C++ done it.
>
> and you're completely right: it is not how C++ done it.

umm...didn't you forget something:

1) it is not how C# done it.
2) it is not how C# done it.

1) it is not how Java done it.
2) it is not how Java done it.

psychoticRabbit wrote:

> On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote:
>> psychoticRabbit wrote:
>>
>>> There are two problems I see:
>> 1) it is not how C++ done it.
>> 2) it is not how C++ done it.
>>
>> and you're completely right: it is not how C++ done it.
>
> umm...didn't you forget something:
>
> 1) it is not how C# done it.
> 2) it is not how C# done it.
>
> 1) it is not how Java done it.
> 2) it is not how Java done it.

ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa!