On Saturday, 19 May 2018 at 09:49:39 UTC, KingJoffrey wrote:
> 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

Coding standards are good enough for Java but not for D?

On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
> 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.

If you have
sealed class A {
   private {
       // members
   }
}
Then you can't use the defualt 'private' if you need it for a specific member.

But if sealed is an access type of a member, 99% you will use sealed insted private in a class, so it is not redundant.

class A {
   sealed {
       // members
   }
   private int friendMember;
}

And you use private keyword only if you need to access that variable from a class/function/struct.. in the same module, like a friend.

On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
> If class level protection is added, please do not call it sealed.
> People from c++ might be suprised by 'private' already. We do not have to confuse those c#ies too.

I thought the same.


> Module level protection is enough to hide implementation details though. So while i do understand why you want this in D, i don't think it is worth it to complicate the language for something you can work around easily by putting the classes in their own modules.

I wouldn't consider putting classes into own modules a workaround. In my opinion it's more or less the solution.

On Saturday, 19 May 2018 at 17:15:45 UTC, Neia Neutuladh wrote:
> On Saturday, 19 May 2018 at 09:49:39 UTC, KingJoffrey wrote:
>> 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
>
> Coding standards are good enough for Java but not for D?

Coding standards are required for any quality development.

How many in the D community have, let alone follow, coding standards when coding in D?

The problem with D, is that everything is essentially unsafe, by default.

To get safety, you have to implement a variety of coding standards, that are simply not required as much in other mainstream langauges. The worst for me, is that you have to implement 'a one class per module coding standard' (because otherwise your privates just suddenly morph into public), just to ensure the safety of your interface from human error. That's crazy!

In any case...development is moving towards safer langauges, and towards safer by default.

D has a lot to catch up with, cause other langauges are decades ahead here.

That's why I see D has this little boutique langauges, for programmers that just want to get away with doing whatever - by default.

On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:
> On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
>> If class level protection is added, please do not call it sealed.
>> People from c++ might be suprised by 'private' already. We do not have to confuse those c#ies too.
>
> I thought the same.
>
>
>> Module level protection is enough to hide implementation details though. So while i do understand why you want this in D, i don't think it is worth it to complicate the language for something you can work around easily by putting the classes in their own modules.
>
> I wouldn't consider putting classes into own modules a workaround. In my opinion it's more or less the solution.

Requiring such a restrictive 'solution', just to protect your interface from human error, is a solution for some, and not others.

open your mind a little.

On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote:
>
> If you have
> sealed class A {
>    private {
>        // members
>    }
> }
> Then you can't use the defualt 'private' if you need it for a specific member.
>
> But if sealed is an access type of a member, 99% you will use sealed insted private in a class, so it is not redundant.
>
> class A {
>    sealed {
>        // members
>    }
>    private int friendMember;
> }
>
> And you use private keyword only if you need to access that variable from a class/function/struct.. in the same module, like a friend.

I agree. But then we end up with what D should have implemented in the first place - C++ friends ;-)

(and in fact, quality software development should rarely, if ever, require the use of friend (which is just a managed way of breaking encapsulation - but, its managed, and managed by the programmer explicitly).

But in D, everything is your friend - you don't get to manage anything - which even to the dumbest of us, must suggest some impact on the quality of the software that will get developed in D. So, now, we need to consider absurd coding standards to get around this facebook style friendship problem (like implementing the proposed 'one class per module' crap - and btw. that is the purest form of OOP - so D actually forces you into this purest form of OOP - even other mainstream OOP langauges don't force that on you).

There is absolutely no reason why D cannot have both (the current way D does it, and the C++ way). It's obviously technically possible. It's obvious it would attract a great deal more programmers to D. It doesn't really complicate the language at all - that's just an excuse not to change. And, it's obvious, that protecting the interface would result in better quality software. It's a core fundamental principle of quality software.

It's just a matter of getting more diverse people into the D 'community'.

But I get the feeling that's not what most D people want. The status quo is pretty comfortable for many, it seems.

Maybe in decade time, if/when D v3 comes out. But I won't be holding my breath.

On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
> On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote:
>
> But in D, everything is your friend - you don't get to manage

You want to be taken seriously and yet you repeat false statements over and over again.


> There is absolutely no reason why D cannot have both (the current way D does it, and the C++ way). It's obviously technically possible.

Being technically possible or even easy to implement is not an argument for including something.


> It's obvious it would attract a great deal more programmers to D.

Pure conjecture. You don't know why people choose not to use D, you know why you choose not to use it. Assuming your opinion is shared by all these supposed people is at best naive at worst an indication of narcissism.

I'll assume for now that you are young, idealistic and naive.


> It doesn't really complicate the language at all - that's just an excuse not to change. And, it's obvious, that protecting the interface would result in better quality software. It's a core fundamental principle of quality software.
>
> It's just a matter of getting more diverse people into the D 'community'.

Yes because if a group of people don't accept your argument about something obviously there is something wrong with them.

OK it's starting to look more like narcissism.


> But I get the feeling that's not what most D people want. The status quo is pretty comfortable for many, it seems.

No shit... you're just getting that feeling now? You remind me of my teenage son, it takes about 100 times of telling him something before it sticks in his head.

Let me ask you this...

How do you get comfortable with something? By using it, trying it, and finding that it works. You don't get comfortable with having a stone in your shoe, so if this feature was the nightmare you say it is all these people using D wouldn't be OK with it.

But again it's utterly pointless because you cannot grasp that. You are unable to even consider that something "other" might work. You are a zealot in that respect, that's why you exaggerate, misrepresent the other side of the argument, predict doom for the heathens, and never budge on your position.

Anyway... feel free to misrepresent what I've said, engage in hyperbole, snip the parts you cant argue with, speak for all the people who chose not to use D, tell D it's doomed if they don't do what you say, it'll never be popular, that it's all idiotic. Etc...

On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote:
> On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
>> On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote:
>>
>> But in D, everything is your friend - you don't get to manage
>
> You want to be taken seriously and yet you repeat false statements over and over again.
>
>
>> There is absolutely no reason why D cannot have both (the current way D does it, and the C++ way). It's obviously technically possible.
>
> Being technically possible or even easy to implement is not an argument for including something.
>
>
>> It's obvious it would attract a great deal more programmers to D.
>
> Pure conjecture. You don't know why people choose not to use D, you know why you choose not to use it. Assuming your opinion is shared by all these supposed people is at best naive at worst an indication of narcissism.
>
> I'll assume for now that you are young, idealistic and naive.
>
>
>> It doesn't really complicate the language at all - that's just an excuse not to change. And, it's obvious, that protecting the interface would result in better quality software. It's a core fundamental principle of quality software.
>>
>> It's just a matter of getting more diverse people into the D 'community'.
>
> Yes because if a group of people don't accept your argument about something obviously there is something wrong with them.
>
> OK it's starting to look more like narcissism.
>
>
>> But I get the feeling that's not what most D people want. The status quo is pretty comfortable for many, it seems.
>
> No shit... you're just getting that feeling now? You remind me of my teenage son, it takes about 100 times of telling him something before it sticks in his head.
>
> Let me ask you this...
>
> How do you get comfortable with something? By using it, trying it, and finding that it works. You don't get comfortable with having a stone in your shoe, so if this feature was the nightmare you say it is all these people using D wouldn't be OK with it.
>
> But again it's utterly pointless because you cannot grasp that. You are unable to even consider that something "other" might work. You are a zealot in that respect, that's why you exaggerate, misrepresent the other side of the argument, predict doom for the heathens, and never budge on your position.
>
> Anyway... feel free to misrepresent what I've said, engage in hyperbole, snip the parts you cant argue with, speak for all the people who chose not to use D, tell D it's doomed if they don't do what you say, it'll never be popular, that it's all idiotic. Etc...

Come on Dave.

18+ years, and still less than 1000 programmers.

As I've said, I can have more that one class in a file in a variety of different mainstream languages, which represent about 20 million developers, and still have the compiler protect that interface from abuse, including accidental misuse.

You cannot get this in D, and yet 20 million developers have had this for decades.

When they come over to D, their' told, stuff you, we don't do it that way in D, and btw, we don't care about your ideas on how we could easily get D to do it both ways. We prefer our own way, so you get stuffed.

That's kind of what I've hearing from the D community.

Of course, that kind of attitude can only invite the same attitude back to the D community.

Let's hope you truly don't represent the D community, cause then my comments are not hyperbole, they are fact.

On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:
>
> I wouldn't consider putting classes into own modules a workaround. In my opinion it's more or less the solution.

I'll add your solution into my article - but, I'm not sure it really addresses my problem statement.

The Problem Statement (being drafted still):
---------------------
In the D programming language, the semantics of the access-level modifier 'private' is likely very different to what a large number of programmers from object-oriented, and class-oriented languages, might expect.

In D, the module (not the class) is the overarching entity, and one that encompasses all other entities within the module.

In D, The module can contain (and typically would contain) a variety of types - functions, structs, classes and so on.

If a module contains a class type however, and that class has a private access modifier on it's members, then that private access modifier becomes moot (within the module), because all the surrounding code in that module can directly access (and even modify) those private members.

The module implicitly morphs a 'private' access modifier, into a 'private-but-also-module-public' modifier.

The programmer has no control over this implicit conversion of the access modifier.

This would be unfamiliar, and unexpected, to a very large number of programmers from languages where 'private' has an established and well-defined semantic as being the most restrictive form of access to a class member.

Unfortunately, in the D programming language, there is simply no way to declare a member of a class to be private, and prevent surrounding code (within the module) from accessing it.

The D module, will implicitly change the semantics of your code.


The Implications:
----------------
..to do....

On Monday, 21 May 2018 at 03:19:34 UTC, KingJoffrey wrote:
> On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote:
>> On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
>>> On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote:
>> Anyway... feel free to misrepresent what I've said, engage in hyperbole, snip the parts you cant argue with, speak for all the people who chose not to use D, tell D it's doomed if they don't do what you say, it'll never be popular, that it's all idiotic. Etc...
>
> Come on Dave.
>
> 18+ years, and still less than 1000 programmers.

Do you have a citation for that? I have no idea how many users there are tbh.


> As I've said, I can have more that one class in a file in a variety of different mainstream languages, which represent about 20 million developers, and still have the compiler protect that interface from abuse, including accidental misuse.

Delphi had the exact same thing and was probably the second largest IDE/Development platform on Windows for a very long time. The idea that it is a make or break feature is a figment of your imagination.


> You cannot get this in D, and yet 20 million developers have had this for decades.

20 million developers have had the friend feature for decades, it didn't stop Java becoming huge without it.

The point is you constantly make logical fallacies of that sort... A has feature B and A is popular so it follows that to be popular you must implement B.

And if I was taking your tone and attitude in pointing this out I would call that idiotic and by implication would be calling you an idiot. I'm not by the way, I'm being mature for once :) and just pointing it out without labelling you.


> When they come over to D, their' told, stuff you, we don't do it that way in D, and btw, we don't care about your ideas on how we could easily get D to do it both ways. We prefer our own way, so you get stuffed.

Many people have engaged with you on your ideas. But lets be honest why should they care about your ideas when you clearly dont care about what they are saying? You have your position that "private means private" and that is the end of it. Nothing anyone can say will change your mind about that. That's why it's pointless, why talking to you is pointless.

And you quickly resort to being derogatory when you dont get your own way, for example "LOL less than 1000 users after 15 years". Stuff like that. And you want to be taken seriously?

BTW this is a user newsgroup it's not the steering group or the boardroom. Why on earth would you think you can change the direction of the language by shouting loudly in the local boozer?


> That's kind of what I've hearing from the D community.

People pointing out flaws in your argument, saying this is what you have to do to get your ideas accepted and these are the kind of issues you will have to overcome, is not telling you to get stuffed.

The problem is you dont seem to handle people disagreeing with you very well, you take it personally, that's why you resort to hyperbole and misrepresenting their position. You react emotionally instead of calm honest assessment of the facts.

If people say "but D works for me, I like this feature" you say it's idiotic and a sign of small language mentality.


> Of course, that kind of attitude can only invite the same attitude back to the D community.

Go back and read over both threads, people weren't rude to you. They basically said "huh works for me" and "takes a lot to get a change accepted".


> Let's hope you truly don't represent the D community, cause then my comments are not hyperbole, they are fact.

I have very little to do with anything here tbh, i just tinker in D, dont have time for much more than that.