On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote:
> da dah dah....
> da dah dah dahh  da d ....
> ..
> .....
> ... da dah..
> ..da..
> da ...da....dada.........da...da........da.........

Thanks Dave.

Your contributions to the discussion have been really insightful, and most valuable.

I'm sure we can all learn from your great wisdom.

Now, for the benefit of those who haven't followed these discussions, so that you too can benefit from Dave's keen insight, I'll sum up Daves' stupendous contribution like this:

"Ours is not to reason why; Ours is but to do or die,"

Thanks again Dave.

On Monday, 21 May 2018 at 09:56:22 UTC, KingJoffrey wrote:
> On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote:
>> da dah dah....
>> da dah dah dahh  da d ....
>> ..
>> .....
>> ... da dah..
>> ..da..
>> da ...da....dada.........da...da........da.........
>
> Thanks Dave.
>
> Your contributions to the discussion have been really insightful, and most valuable.
>
> I'm sure we can all learn from your great wisdom.
>
> Now, for the benefit of those who haven't followed these discussions, so that you too can benefit from Dave's keen insight, I'll sum up Daves' stupendous contribution like this:
>
> "Ours is not to reason why; Ours is but to do or die,"
>
> Thanks again Dave.

If you resort to mockery, then that means you have lost the argument.

On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
> class A {
>    private int x;
>    private(this) int y;
> }

Instead of such a syntax if this ever comes to be, we could just introduce a new keyword into the language.

class A {
   private int x;
   closed int y; //closed for acces outside this class.
   owned int z; //owned by this class.
   inside int zz; //only accessible inside this class.
}

As far as I can tell we don't need a `private(this)` or `private(classname)` declaration. I'd much rather have a keyword specifically designed for the thing that it does.

D is at the point that there's already legacy code so you can't use the `private` keyword anymore whitout doing something funky with defining it private to class scope any other given scope. It would also raise the question of "Why can't I have `private(functionName)`? Does that make sense?"

I do see how this could be usefull if you had a 6000 line static function that you don't want to have access to a private member that is defined in thesame module. But then again, one could simply extract it to its own module, reference the former module and use those classes.

I personally find having no class private members incredibly usefull since I can use them for unittests that way.
Then I can enforce the existance of a class member regardless of its scope to exist and therefore enforce the use of a given approach to the problem a class is solving.
While you might say that a unittest shouldn't acces private members and only public members, there are plenty of testcases where one would want to write a unittest to set a given variable via public function and then test if the appropriate private fields are properly set. While this sounds like a trivial usecase I believe it to be a verry big one in practice since it removes a lot of boilerplate code from your unit-tests, together with exposing the innards of a class's implementation to the outside world just so you can unit-test it. The last point is something I don't like about OOP + TDD in languages like C# or java and I think D has (accidentally) solved this in a beautiful way, and I would dislike to see this feature go.

On Monday, 21 May 2018 at 13:39:12 UTC, Sjoerd Nijboer wrote:
>
> While you might say that a unittest shouldn't acces private members and only public members, there are plenty of testcases where one would want to write a unittest to set a given variable via public function and then test if the appropriate private fields are properly set. While this sounds like a trivial usecase I believe it to be a verry big one in practice since it removes a lot of boilerplate code from your unit-tests, together with exposing the innards of a class's implementation to the outside world just so you can unit-test it.

I have to ask, why isn't that unittest your talking about, within the scope of the class? Why is it outside the class, testing private innards of the class?

I have trouble getting my head around this.

> The last point is something I don't like about OOP + TDD in languages like C# or java and I think D has (accidentally) solved this in a beautiful way, and I would dislike to see this feature go.

I'm not sure I understand this. You mean you don't like 'private'?

You think an object doesn't have a right, to privacy?

Are you one of those facebook employees?

And who suggested getting rid of anything?

On Monday, 21 May 2018 at 13:36:32 UTC, 12345swordy wrote:
>
> If you resort to mockery, then that means you have lost the argument.

I prefer to think of it as sarcasm, not mockery.

Sarcasm is a form of intelligent expression, to wield however you see fit
(not unlike a module in D ;-)

For me, sarcasm is the ultimate weapon, against stupidity.

Don't confuse sarcasm with mockery.

Mockery involves hostility, and is a tool the weak use, to bully others.

On Monday, 21 May 2018 at 14:30:21 UTC, KingJoffrey wrote:
> On Monday, 21 May 2018 at 13:39:12 UTC, Sjoerd Nijboer wrote:
>>
>> While you might say that a unittest shouldn't acces private members and only public members, there are plenty of testcases where one would want to write a unittest to set a given variable via public function and then test if the appropriate private fields are properly set. While this sounds like a trivial usecase I believe it to be a verry big one in practice since it removes a lot of boilerplate code from your unit-tests, together with exposing the innards of a class's implementation to the outside world just so you can unit-test it.
>
> I have to ask, why isn't that unittest your talking about, within the scope of the class? Why is it outside the class, testing private innards of the class?
>
> I have trouble getting my head around this.

This hypotetical unittest is testing a hypotetical class in a hypotetical module with hypotetical properties.
Why is it outside the class? I don't know, maybe it needs access to two classes which are defined in thesame module. But also out of personal preference, I don't like random unittest declarations inside my class. Regardless, I think it's important for unittests to be able to do this.

>> The last point is something I don't like about OOP + TDD in languages like C# or java and I think D has (accidentally) solved this in a beautiful way, and I would dislike to see this feature go.
>
> I'm not sure I understand this. You mean you don't like 'private'?
>
> You think an object doesn't have a right, to privacy?
>
> Are you one of those facebook employees?
>
> And who suggested getting rid of anything?

Nope, I'm simply a bystander who sees lack of class scope as a "feature" of D that is usefull in some cases while not hurting idiomatic OOP as long as you only define a single class (+ unittests) inside a module.
If you want that too but still want static functions outside classes, you can mix in C# extension methods paradigm into D. Which is why I don't see any reason to add this.

But besides that, I just wanted to put forward that we don't need to do `private(this)` or `private(className)` if this ever became a language feature because it would be confusing as to why it could bind to class or struct scope but not to any other scope and might as well introduce a new keyword which isn't regularly used in other languages like `sealed` but could instead come up with a new one.
I felt that my response was incomplete whitout adding I think that the concept of a class private in D would not be a good idea.

Also, I would verry much much like it if you would not resort to comparing me to "one of those facebook employees." It's just setting a mood for the conversation which no one likes, regardless what anyone thinks about facebook employees.

On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:
>
> Also, I would verry much much like it if you would not resort to comparing me to "one of those facebook employees." It's just setting a mood for the conversation which no one likes, regardless what anyone thinks about facebook employees.

people are so touchy here....

what's happended to the world...it's all going crazy...like some ideology is taking over peoples minds.... I don't get it...

you just can't say anything anymore, with offending someone... it's just ridiculous!

personally, I see it as a new form of bullying -- social bullying I'll call it.

And I really, really, really... don't like bullies!

On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:
>
>
> Nope, I'm simply a bystander who sees lack of class scope as a "feature" of D that is usefull in some cases while not hurting idiomatic OOP as long as you only define a single class (+ unittests) inside a module.
> If you want that too but still want static functions outside classes, you can mix in C# extension methods paradigm into D. Which is why I don't see any reason to add this.
>

And there's the point I'm trying to make.

Why should a c# programmer come to D, if, in order to keep private private, they have to resort to this. It makes no sense. They may as well just stick to C#.

Same for Java programmers, same for C++ programmers (class-oriented ones).

As it is, D tells them, stuff you, private is now private-but-module-public, and you have no say it.

My suggestions are about resolving this, in order to attract more programmers to D, because I doubt I'm the only person in the world, that believes an object has a right to privacy.

But as I've said, I do really get the feeling the D community does not want more programmers, unless they are like them.

On Monday, 21 May 2018 at 15:07:39 UTC, KingJoffrey wrote:
> My suggestions are about resolving this, in order to attract more programmers to D, because I doubt I'm the only person in the world, that believes an object has a right to privacy.

Of course you are not the only person that believes that.
To have full private access in module scope is like you live in a building and there are no walls between apartments.

On Monday, 21 May 2018 at 09:56:22 UTC, KingJoffrey wrote:
> On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote:
>> da dah dah....
>> da dah dah dahh  da d ....
>> ..
>> .....
>> ... da dah..
>> ..da..
>> da ...da....dada.........da...da........da.........
>
> Thanks Dave.
>
> Your contributions to the discussion have been really insightful, and most valuable.
>
> I'm sure we can all learn from your great wisdom.
>
> Now, for the benefit of those who haven't followed these discussions, so that you too can benefit from Dave's keen insight, I'll sum up Daves' stupendous contribution like this:
>
> "Ours is not to reason why; Ours is but to do or die,"
>
> Thanks again Dave.

And yet again when he cant argue the point he sticks his fingers in his ears and starts shouting "la la la I cant hear you" like a spoilt little child.

Well done Joffers.