Thread overview
Dlang and POO
Jun 21
user1234
Jun 22
user1234
Jun 23
user1234
Jun 23
user1234
Jun 24
deadalnix
Jun 24
deadalnix
June 21

Hello to all,

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

I test the following code:

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

June 21

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:

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.

June 21

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

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

June 21

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

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

June 22

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

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

June 23

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.

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.

June 23

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.

June 23

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.

June 24

On Wednesday, 23 June 2021 at 07:04:05 UTC, user1234 wrote:

>

Who cares could write a DIP.

What problem does this solve?

June 24

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?