On Sunday, 5 June 2022 at 19:41:36 UTC, Dom Disc wrote:
> On Saturday, 4 June 2022 at 14:40:10 UTC, zjh wrote:
>> For me, it would be better ,if I could encapsulate at `class level`.In any case, I don't want the `outside` to affect `my class inside`.
>
> C++ "class level privacy" needs to have "friends", else you cannot create top-level functions that have access to the private members.
> But these "friends" destroy the whole purpose of "private":
> Anybody can declare friends, without even touching the file where the class is defined, and thereby access things that shouldn't even be visible to them (implementation details or even security relevant things)!
> In D you need to change the file where a class is defined if you need to access its privates - this is much easier visible and in a larger team can't be hidden from the person responsible for that class.

What I like about C++ friend concept, is that you explicately know who is a friend and who isn't. It's declared right there in the class.

In a D module, everything could be a friend. Everything! You'll have to look at ALL the code in the module to determine that - as opposed to C++, where you can find this information right there in the class declaration.

Imagine if everyone in your street was your friend, and they could come around willy nilly and do as they please, in your nice, encapsulated home.

Now, to be fair, it's nice to have a friend around. But all the time!!! Doing whatever the %F#V they want!!!

On Monday, 6 June 2022 at 01:05:44 UTC, forkit wrote:
>

I think this statement differentiates the C++ approach, to D's approach:

C++ approach: "Use a member when you can, and a friend when you have to."
https://isocpp.org/wiki/faq/friends

D approach: What nonsense! Why keep private things private! Just make everything a friend.

On Monday, 6 June 2022 at 01:23:41 UTC, forkit wrote:
>

when your boss isn't really your friend:

// ----

module test;
@safe :

class Employee
{
  private:
    double salary;

  public:
    double getSalary()
    {
        return salary;
    }

    void setSalary(double amount)
    {
        try
        {
            if (amount < 100_000 )
                throw new Exception("msg");

            salary = amount;
        }
        catch (Exception e)
        {
            import std.stdio;
            writeln("No. Don't be an ass! Try again.");
        }
    }

}

class Boss
{
  private:
    Employee e;
}

// compile with: -main -unittest
unittest
{
    Boss boss = new Boss();
    boss.e = new Employee();

    //boss.e.setSalary(100_000.0); // The objects invariant WILL be upheld (at runtime).

    boss.e.salary = 1.0; // oh. what a cu%# of a boss!
                         // If only D had @private - or, if I had 'remembered' to use the member function

    import std.stdio : writefln;
    import std.math;
    writefln("The employees salary is: %s", (isNaN(boss.e.getSalary())) ? (0) : (boss.e.getSalary()));
}

// -----

On Monday, 6 June 2022 at 01:05:44 UTC, forkit wrote:
> On Sunday, 5 June 2022 at 19:41:36 UTC, Dom Disc wrote:
>> On Saturday, 4 June 2022 at 14:40:10 UTC, zjh wrote:
>>> For me, it would be better ,if I could encapsulate at `class level`.In any case, I don't want the `outside` to affect `my class inside`.
>>
>> C++ "class level privacy" needs to have "friends", else you cannot create top-level functions that have access to the private members.
>> But these "friends" destroy the whole purpose of "private":
>> Anybody can declare friends, without even touching the file where the class is defined, and thereby access things that shouldn't even be visible to them (implementation details or even security relevant things)!
>> In D you need to change the file where a class is defined if you need to access its privates - this is much easier visible and in a larger team can't be hidden from the person responsible for that class.
>
> What I like about C++ friend concept, is that you explicately know who is a friend and who isn't. It's declared right there in the class.
>
> In a D module, everything could be a friend. Everything! You'll have to look at ALL the code in the module to determine that - as opposed to C++, where you can find this information right there in the class declaration.
>
> Imagine if everyone in your street was your friend, and they could come around willy nilly and do as they please, in your nice, encapsulated home.
>
> Now, to be fair, it's nice to have a friend around. But all the time!!! Doing whatever the %F#V they want!!!

This is such a non-issue, the mindset in D simply needs to be encapsulation boundary is at the module level. All this huff and puff of wasted of energy goes away at that point and your designs will actually be much cleaner than in C++. This is a pure ideological debate and it is actually very useful to have module level encapsulation.

It is even more of a non-issue when D has thread-local variables by default.

On Monday, 6 June 2022 at 04:01:27 UTC, norm wrote:
>
> This is such a non-issue, the mindset in D simply needs to be encapsulation boundary is at the module level. All this huff and puff of wasted of energy goes away at that point and your designs will actually be much cleaner than in C++. This is a pure ideological debate and it is actually very useful to have module level encapsulation.
>

I agree that it's a non-issue, in that I haven't argued that isn't very useful
to have module level encapsulation.

Why ya'll always twist my argument to suit your own?

My argument is clear. It would be 'nice to have' 'an option' for there to be a genuine private component of a class. Not pseudo 'private', but genuine @private.

An option to bring back an actual class type.

And can I remind everyone, yet again, my argument is NOT that we shouldn't have module level encapsulation!

Also, please don't tell me that I need to think like D wants me to think.

Cause, no, I don't. And I won't.

On Wednesday, 1 June 2022 at 01:54:52 UTC, H. S. Teoh wrote:
>
btw. if seems we've higjacked your thread.

sorry about that.

Seems like I raised a very provocative idea, indeed.

I'll refrain from any more posts.

However, I'd still like to know *your* motivation for the code you presented.

(unless you also think it is 'too provocative an idea' to comment on any further).

On 06/06/2022 9:39 PM, Basile B. wrote:
> reminder: we have [already 5]

Lets remove the linker directive, export :D