www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dlang and POO

reply christophe__c <carpentier-christophe hotmail.fr> writes:
Hello to all,

I'm starting to program in Dlang. I use for the moment the online 
editor.

I test the following code:

```D
import std;

class User
{

     private string name;

private:
     string firstname;
     int age;

public:

     override string toString()
     {
         return (format("User: %s %s - (%s)", this.name, 
this.firstname, this.age));
     }

};

void main()
{

     auto bob = new User();
     bob.name = "Bob";
     bob.firstname = "McDean";
     bob.age = 15;

     writeln(bob);

}
```

and I don't understand why I can modify private members from 
outside my class.

I had understood that it was required to create accessors to have 
this behavior.

Thanks in advance to all for your welcome and your answers.

Christophe__c
Jun 21
next sibling parent user1234 <user1234 12.de> writes:
On Monday, 21 June 2021 at 10:01:03 UTC, christophe__c wrote:
 Hello to all,

 I'm starting to program in Dlang. I use for the moment the 
 online editor.

 I test the following code:

 ```D
 import std;

 class User
 {

     private string name;

 private:
     string firstname;
     int age;

 public:

     override string toString()
     {
         return (format("User: %s %s - (%s)", this.name, 
 this.firstname, this.age));
     }

 };

 void main()
 {

     auto bob = new User();
     bob.name = "Bob";
     bob.firstname = "McDean";
     bob.age = 15;

     writeln(bob);

 }
 ```

 and I don't understand why I can modify private members from 
 outside my class.

 I had understood that it was required to create accessors to 
 have this behavior.

 Thanks in advance to all for your welcome and your answers.

 Christophe__c
Ah this gain ;) in D "private" is related to the module scope, not the aggregate scope. So at the module scope you can see private declarations even if the "local" scope is unrelated.
Jun 21
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/21/21 6:01 AM, christophe__c wrote:
 Thanks in advance to all for your welcome and your answers.
Welcome to the community! Just FYI, these kinds of questions should go into the [learn forum](https://forum.dlang.org/group/learn) And user1234's answer is correct, D's private applies to module scope, not struct/class scope. The main reason is so D can avoid the `friend` requirements of C++. It's also pretty reasonable, since anyone who can edit the class can also edit the rest of the file. However, it can make things difficult when proving correctness if you don't have a "one class per module" setup. -Steve
Jun 21
parent reply christophe__c <carpentier-christophe hotmail.fr> writes:
On Monday, 21 June 2021 at 13:09:31 UTC, Steven Schveighoffer 
wrote:
 On 6/21/21 6:01 AM, christophe__c wrote:
 Thanks in advance to all for your welcome and your answers.
Welcome to the community! Just FYI, these kinds of questions should go into the [learn forum](https://forum.dlang.org/group/learn) And user1234's answer is correct, D's private applies to module scope, not struct/class scope. The main reason is so D can avoid the `friend` requirements of C++. It's also pretty reasonable, since anyone who can edit the class can also edit the rest of the file. However, it can make things difficult when proving correctness if you don't have a "one class per module" setup. -Steve
Good evening Steve, Good evening user1234 Thank you very much for your answers. I have to admit that I am disappointed by this behavior. I'm sorry I posted in the wrong forum. Good evening to you. -Christophe
Jun 21
next sibling parent reply user1234 <user1234 12.de> writes:
On Monday, 21 June 2021 at 20:18:03 UTC, christophe__c wrote:
 On Monday, 21 June 2021 at 13:09:31 UTC, Steven Schveighoffer 
 wrote:
 On 6/21/21 6:01 AM, christophe__c wrote:
 Thanks in advance to all for your welcome and your answers.
Welcome to the community! Just FYI, these kinds of questions should go into the [learn forum](https://forum.dlang.org/group/learn) And user1234's answer is correct, D's private applies to module scope, not struct/class scope. The main reason is so D can avoid the `friend` requirements of C++. It's also pretty reasonable, since anyone who can edit the class can also edit the rest of the file. However, it can make things difficult when proving correctness if you don't have a "one class per module" setup. -Steve
Good evening Steve, Good evening user1234 Thank you very much for your answers. I have to admit that I am disappointed by this behavior. I'm sorry I posted in the wrong forum. Good evening to you. -Christophe
As suggested ("this again") this is a recurrent question. I have myself nothing against strict privacy but the problem is that it would require a new keyword as obviously nobody wants to change the semantics of "private".
Jun 21
parent reply user1234 <user1234 12.de> writes:
On Tuesday, 22 June 2021 at 02:37:28 UTC, user1234 wrote:
 would require a new keyword
I think actually that "super private" would work. ```d struct S { super private: static int a; private: static void test() { a = 0; } } void test() { S.test(); // Ok S.a = 0; // NG } ``` Who cares could write a DIP.
Jun 23
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 23 June 2021 at 07:04:05 UTC, user1234 wrote:
 On Tuesday, 22 June 2021 at 02:37:28 UTC, user1234 wrote:
 would require a new keyword
I think actually that "super private" would work.
We already have the means to handle this for people who really really want it. Make the module a package and put all of the SuperSecretSauce ingredients in their own modules. - mymodulepackage -- package.d -- opensecrets.d -- supersecretsauce1.d -- supersecretsauce2.d Package protection lets you share whatever needs to be shared between each module, you are able to fully restrict access to private members, and clients are able to `import mymodulepackage` without worrying about the details.
Jun 23
parent user1234 <user1234 12.de> writes:
On Wednesday, 23 June 2021 at 07:29:54 UTC, Mike Parker wrote:
 On Wednesday, 23 June 2021 at 07:04:05 UTC, user1234 wrote:
 On Tuesday, 22 June 2021 at 02:37:28 UTC, user1234 wrote:
 would require a new keyword
I think actually that "super private" would work.
We already have the means to handle this for people who really really want it. Make the module a package and put all of the SuperSecretSauce
ah lol, speaking of hidden secrets, I did not know that you handled sarcasms with such a talent.
 ingredients in their own modules.
I know i know... we are talking on things that are extremely simple to implement but that wont wont be done by design principle.
Jun 23
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Wednesday, 23 June 2021 at 07:04:05 UTC, user1234 wrote:
 Who cares could write a DIP.
What problem does this solve?
Jun 24
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Monday, 21 June 2021 at 20:18:03 UTC, christophe__c wrote:
 Thank you very much for your answers. I have to admit that I am 
 disappointed by this behavior.
Why are you disappointed?
Jun 24