On Friday, 18 May 2018 at 17:28:59 UTC, Steven Schveighoffer wrote:
>
> You can "simulate" this by putting the classes into their own submodules of the same package.
>

That just another hack to get around the problem.

It's not a solution to removing the problem, from being a problem.

(yeah, I know, not everyone thinks it's a problem.. been there done that).

private(this) is a lot easier, than being told you need to redesign your whole class layout to accomodate D's 'private is really public' concept.

Lets get rid of the problem (that prevents many from using D in the first place), rather that constatnly come up with new ways of telling them find a way around it.

btw. I only know of two reasons why private is public so far (from discussions).

1 - Voldemort types (don't know what it is, and don't care).

2 - unittests (but, if the unit tests, testing your class, are outside your class accessing it's private parts, then I have trouble considering them to be unittests at all.

On Friday, 18 May 2018 at 20:30:21 UTC, Dave Jones wrote:
>
> So lets stop the pointless gentle mockery and concentrate solely on the pointless.
>
> Sounds like a plan!

you mean, follow your lead?  now there's a plan!

I like robust conversations too ;-)

But some semblance on sanity, in that robustness, would also be useful.

On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:
> On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
>> On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
>>
>> class A {
>>    private int x;
>>    private(this) int y;
>> }
>>
>
> I agree that this looks a bit strange.
> My initial proposal was "sealed" instead "private(this)" today.

Mmm.. that brings me back to the idea of sealed at the class level again.

class A
{
   private int x;
   private(this) int y;  // imagine if you have lots of private variables.
                         // this could become pretty anoying - and kinda redundant.
}

class A
{
   private int x;
   sealed int y; // again, what if you have lots of private variables that
                 // that you really want sealed.
}


// Now. Back to the idea of sealed.
// abosolute consistency of your private variables.
// no redundancy.
// no some 'private', some 'sealed' confusion.
// no some 'private' (but really public) some 'private(this) .. confusion.
//
sealed class A{
    private int x;
    private int y;
}

downside, is adding a new keyword, and getting agreement on what that new keyword should be.

So I've come full circle again, and believe my idea is worth further consideration.

On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:
> On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
>> On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
>>
>> class A {
>>    private int x;
>>    private(this) int y;
>> }
>>
>
> I agree that this looks a bit strange.
> My initial proposal was "sealed" instead "private(this)" today.

I'm really struggling to come up with any acceptable use case, whereby my class would want to have both private and sealed variables.( whether the word sealed is used, or private(this) is used, is irrelevant to this point though).

Can anyone come up with use case for this code below?

(It may well encourage even poorer software engineering, that private morhping into public).

-----
class A
{
   private int x; // ok, really public within the module.
   sealed int y; // now really private within the module.
}
----

On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
> So I've come full circle again, and believe my idea is worth further consideration.

how about this (use a proper annotation).

This will be less likely to confuse anyone from other languages.

e.g

-------------------
module test;

@safeinterface class Dog
{
    private string noiseType = "woof";

    public string makeNoise()
    {
        return this.noiseType;
    }
}

void main()
{
    import std.stdio;

    auto dog = new Dog;
    dog.noiseType = "meow"; // no way jose - requires use of the safe interface!
    writeln(dog.makeNoise()); // phew! cause dogs can only bark.
}
-------------------

On Saturday, 19 May 2018 at 07:57:39 UTC, KingJoffrey wrote:
> On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
>>[...]
> ----------------
> module test;
>
> @safeinterface class Dog
> {
>     private string noiseType = "woof";
>
>     public string makeNoise()
>     {
>         return this.noiseType;
>     }
> }
>
> void main()
> {
>     import std.stdio;
>
>     auto dog = new Dog;
>     dog.noiseType = "meow"; // no way jose - requires use of the safe interface!
>     writeln(dog.makeNoise()); // phew! cause dogs can only bark.
> }
> -------------------

I ported your example to Java. Surprisingly, it compiled and executed just fine:

--- test.java
class test
{
	static class Dog
	{
		private String noiseType = "woof";

		public String makeNoise()
		{
			return this.noiseType;
		}
	}

	public static void main(String[] args)
	{
		Dog dog = new Dog();
		dog.noiseType = "meow"; // no way jose - requires use of the safe interface!
		System.out.println(dog.makeNoise()); // phew! cause dogs meow.
	}
}
---

On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote:
>
> I ported your example to Java. Surprisingly, it compiled and executed just fine:

All I see, is a class, with static members. How else would it work?

This is the equivalent of my D example, in Java:

( it won't even compile.  phew!  )

--------------
public class test
{
    public static void main(String[] args)
    {
        Dog dog = new Dog();
        dog.noiseType = "meow";              // no way jose
        System.out.println(dog.makeNoise()); // phew! cause dogs don't meow.
    }
}

class Dog
{
    private String noiseType = "woof";

    public String makeNoise()
    {
        return this.noiseType;
    }
}
--------------------

On Saturday, 19 May 2018 at 09:10:32 UTC, KingJoffrey wrote:
> On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote:
>>
>> I ported your example to Java. Surprisingly, it compiled and executed just fine:
>
> All I see, is a class, with static members. How else would it work?
>
> This is the equivalent of my D example, in Java:
>
> ( it won't even compile.  phew!  )
>

The point was encapsulation as you defined it was broken. private members were directly modified outside their class. In your words, everyone was a friend.

On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:
>
> The point was encapsulation as you defined it was broken. private members were directly modified outside their class. In your words, everyone was a friend.

This is why we have coding standards ;-)

https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2017/april/accessing-private-fields-outside-of-classes-in-java.pdf

On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
> Mmm.. that brings me back to the idea of sealed at the class level again.
>
> class A
> {
>    private int x;
>    private(this) int y;  // imagine if you have lots of private variables.
>                          // this could become pretty anoying - and kinda redundant.
> }

All attributes in D work the same way. You can write things like:

class A
{
  @Jsonize:
  private:
  int a;
  string b;

  protected
  {
    long c;
  }

  @safe:
  void privateSafeFunction() {}
  void otherPrivateSafeFunction() {}
}

Perhaps you should learn more about the language before proposing specific changes?