On Sunday, 28 October 2018 at 04:38:53 UTC, unprotected-entity wrote:

> oh... so you accidently typed b.x++ in main().. or someother code outside of the class), instead of b.increment() ...well...to bad.
>

You can make the same mistake inside the class:

class Foo {
   private int x;
   void increment() {...}
   ...
   void doSomethingInternal() { x++; }
}

How is making that mistake outside of that final curly brace any different or any worse? It's all in the same file.

On Saturday, 27 October 2018 at 16:19:03 UTC, Steven Schveighoffer wrote:
>
> This isn't correct. I'd write examples in each of those languages, but don't have the time right now.
>
> -Steve

I have plenty of time ;-)

(in any case, my point is not to make an argument out of this, I was stating a fact).

That D does it differently, is fine, if that's how D want to do it.

But people coming to D, will be very surprised, and will have to come to terms with it, or not.

====== C++ =============

class C
{
  private: int x = 0;
  public: void increment() {++x;}
};

class B : public C {};

int main()
{
    B b;
    b.increment();
    b++; // no way! not in C++

    return 0;
}

===== Java ==============

class C
{
    private int x;
    public void increment() { ++x; }
}

class B extends C {}

public class Program
{
    public static void main(String[] args)
    {
        B b = new B();
        b.increment();
        b++; // seriously. you really think this is going to happen? Not in Java it aint.
    }
}

===== C# ==============

class C
{
    private int x;
    public void increment() { ++x; }
}

class B : C {}

public class Program
{
    public static int Main()
    {
        B b = new B();
        b.increment();
        b++; // forget it. It's not going to happen. Not in C#

        return 0;
    }
}

===== D ========
module test;

class C
{
   private int x;
   public void increment() { ++x; }
}

class B : C {}

void main()
{
    B b = new B;
    b.increment();
    b.x++; // sure, no problem. I'll do that for you, cause I'm D.
}

===== THE END =======

On Sunday, October 28, 2018 2:36:06 AM MDT unprotected-entity via Digitalmars-d wrote:
> On Saturday, 27 October 2018 at 16:19:03 UTC, Steven
>
> Schveighoffer wrote:
> > This isn't correct. I'd write examples in each of those languages, but don't have the time right now.
> >
> > -Steve
>
> I have plenty of time ;-)
>
> (in any case, my point is not to make an argument out of this, I
> was stating a fact).
>
> That D does it differently, is fine, if that's how D want to do it.
>
> But people coming to D, will be very surprised, and will have to come to terms with it, or not.

True enough, but in reality, it seems that most people coming to D don't even notice. After all, none of the code outside of the module containing the class has access to the class' private members, and if you don't try to access the class' private members using any of the other code inside the same module, then you won't notice. Plenty of folks incorrectly assume that D's private works the same as private in other languages, never run into problems with it, and have no clue that it works any differently. It really only matters when you're actually looking to emulate friends, and then you find out pretty fast. Occasionally, it comes up and folks complain about it, but honestly, I don't think that there have been threads complaining about it in the newsgroup more than a handful of times - if that - over the last ten years. Mostly, if it does come up, it's just that's someone is suprised to finally find out that private is private to the module and not the class. I don't think that it's uncommon for folks code for years in D without realizing it. Sure, once someone learns about it, they have to come to terms with it, and they may or may not be unhappy about it, but it's such a non-issue in practice that a lot of folks simply don't notice.

- Jonathan M Davis

On Sunday, 28 October 2018 at 05:28:31 UTC, Mike Parker wrote:
>
> You can make the same mistake inside the class:
>
> class Foo {
>    private int x;
>    void increment() {...}
>    ...
>    void doSomethingInternal() { x++; }
> }
>
> How is making that mistake outside of that final curly brace any different or any worse? It's all in the same file.

Except, that (I assume) a module in D is meant to be more than just a single class.

If that's not the case, then my argument is irrelevant.

If it is the case, then you presumably would have a great deal more code in your module, than you would in a single class. Hence, greater likelihood of mistakingly
accessing a private member of some class defined within the module, somewhere.

In any case, it does undermine the principle of encapsulation (assuming you agree that a class deserves to be a unit of encapsulation).

In, it's nothing more than a convenient hack, really.

There is not a third option here.

On Sunday, 28 October 2018 at 11:27:01 UTC, unprotected-entity wrote:
> On Sunday, 28 October 2018 at 05:28:31 UTC, Mike Parker wrote:

>> How is making that mistake outside of that final curly brace any different or any worse? It's all in the same file.
>
> Except, that (I assume) a module in D is meant to be more than just a single class.
>
> If that's not the case, then my argument is irrelevant.

Modules can contain as many classes as you like or none at all. That doesn't change anything. It's still all in the same file.

>
> If it is the case, then you presumably would have a great deal more code in your module, than you would in a single class.
> Hence, greater likelihood of mistakingly
> accessing a private member of some class defined within the module, somewhere.

And full access to the file to change it if you do make that mistake. No encapsulation broken.

>
> In any case, it does undermine the principle of encapsulation (assuming you agree that a class deserves to be a unit of encapsulation).

In D, the module is the unit of encapsulation, not the class.

On Sun, 28 Oct 2018 04:38:53 +0000, unprotected-entity wrote:
> In C++/Java/C#, x is private to C, as you would expect, since it was declared private to C.

Let's look at a few languages and see exactly what they do.

In C++, x is private to C and any friend types or functions.

In C#, x is private to C (but can be accessed via reflection).

In D, x is private to C and any types or functions defined in the same module.

In Dart, _x is private to C.

In Delphi, x is private to C.

In Go, x is private to that source file. (I believe. It might be private to that directory. I don't care enough to check.)

In Java, x is private to C, all types in which C is nested, and all types nested in any of those types. It can also be accessed via reflection.

In Javascript, x is public. In order to make a private-style variable, you need to use a local variable in the type's constructor. This prevents you from using method syntax in methods referring to that variable; you need to assign closures to fields instead.

In Lua, x is public (or you use the Javascript workaround).

In Perl, x is public.

In Python, __x doesn't exist; it's syntactic sugar for _C__x. _C__x is public.

In Ruby, @x is protected (but can be accessed via reflection).

In Rust, x is private to the module.

In Swift, there are different versions of 'private' for private-to-type and private-to-source-file.

So no, there is no one standard way of doing things that D violates. D uses a system that's tied for second place behind not having private variables at all.

On Sunday, 28 October 2018 at 15:41:47 UTC, Neia Neutuladh wrote:

> In D, x is private to C and any types or functions defined in the same module.

...and can be accessed via reflection (.tupleof). </Pedantry>

On Sunday, 28 October 2018 at 15:47:15 UTC, Stanislav Blinov wrote:
> On Sunday, 28 October 2018 at 15:41:47 UTC, Neia Neutuladh wrote:
>
>> In D, x is private to C and any types or functions defined in the same module.
>
> ...and can be accessed via reflection (.tupleof). </Pedantry>

Actually if you try to use it the compiler complains because D reflection is compile time.

On Sunday, 28 October 2018 at 16:20:06 UTC, Jesse Phillips wrote:
> On Sunday, 28 October 2018 at 15:47:15 UTC, Stanislav Blinov wrote:
>> On Sunday, 28 October 2018 at 15:41:47 UTC, Neia Neutuladh wrote:
>>
>>> In D, x is private to C and any types or functions defined in the same module.
>>
>> ...and can be accessed via reflection (.tupleof). </Pedantry>
>
> Actually if you try to use it the compiler complains because D reflection is compile time.

Actually it doesn't complain ;)

On Sun, 28 Oct 2018 15:47:15 +0000, Stanislav Blinov wrote:
> On Sunday, 28 October 2018 at 15:41:47 UTC, Neia Neutuladh wrote:
> 
>> In D, x is private to C and any types or functions defined in the same module.
> 
> ...and can be accessed via reflection (.tupleof). </Pedantry>

Good point.

I saw a bug report recently implying that this is unintended and subject to change, so maybe that won't remain true for long.