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