On Sunday, 28 April 2024 at 23:32:45 UTC, NotYouAgain wrote:
> The idea is only controversial, because many in the D community are genuiely oop haters.
>
> Once you understand that, you understand the pushback that is needed against them, when this idea is raised.
>
> Also, the suggestion that idea should not be raised except once, is silly.
>
> It should be raised as often as required, to determine whether it can gain necessary support to proceed to a DIP.

This reads like you're going to disregard my advice. If so, I don't think anything I could write would turn your head.

Too bad, as it leads me to the conclusion you're not worth debating the DIP with until you learn to be less combative. Sooner or later other people will conclude the same - probably some have done so already.

> And calling me a socketpuppet because you think I'm the only one pursuing this idea, if not correct. Other people like the idea as well. Their posts are not my posts.

To be clear, whoever instigated those former flame wars I wrote about is who I meant falling into sockpuppetry.

On Monday, 29 April 2024 at 08:34:21 UTC, Dukc wrote:
> On Sunday, 28 April 2024 at 23:32:45 UTC, NotYouAgain wrote:
>> The idea is only controversial, because many in the D community are genuiely oop haters.
>>
>> Once you understand that, you understand the pushback that is needed against them, when this idea is raised.
>>
>> Also, the suggestion that idea should not be raised except once, is silly.
>>
>> It should be raised as often as required, to determine whether it can gain necessary support to proceed to a DIP.
>
> This reads like you're going to disregard my advice. If so, I don't think anything I could write would turn your head.
>
> Too bad, as it leads me to the conclusion you're not worth debating the DIP with until you learn to be less combative. Sooner or later other people will conclude the same - probably some have done so already.
>
>> And calling me a socketpuppet because you think I'm the only one pursuing this idea, if not correct. Other people like the idea as well. Their posts are not my posts.
>
> To be clear, whoever instigated those former flame wars I wrote about is who I meant falling into sockpuppetry.

No, I know Walter will never approve this, no matter want.

He even wanted to get of protected as well.

But the battle is ongoing...

At least in the Swift community, someone was willing to listen:

https://forum.dlang.org/post/tgjilaffuybvpkksmane@forum.dlang.org

On Monday, 29 April 2024 at 09:12:12 UTC, NotYouAgain wrote:
>..

and:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160404/014116.html

Swift made the decision to fix private more than 8 years ago!

On Monday, 29 April 2024 at 13:39:17 UTC, Basile B. wrote:
>
> The D solution is to encourage splitting modules. ...

You could it that way, I guess.

I prefer to say, that D puts the burden of correctness, fully on the programmer.

The Swift community already went through this issue over 8 years ago, and the decided a fix was warranted (and I mean the very, very experienced people who design Swift).

You can see some of those discussion here (and note how professional those discussions are too) - https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html

That any oo programmer that comes to D should have to explain to anyone in the D community the value of an option to declare a private class member and have to argue it for years...no decades.. is just pathetic. I cannot describe it any other way.

Yes, I know people in D disagree. Fine. That doesn't make them right. Does it make me right...well..one can just look at what Swift have done (fixed), Javascript have done (fixed), C++, C#, Java, Haskell....have by design ... and I can go on and on....

As I said before, the proof of a type is in the type of its proof. Not just each class, but each unittest has to go in its own module. It's a totally uncessary burden to place on programmers in order to the design contraint they want on their class type, and appropriate enforcement of that design by the compiler. If people disagree, fine. I don't accept that they are a correct, and the proof is in all the languages I just mentioned. I think those languages represent the vast majority of programmers in the world. D represents less than atom of that amount.

But just remember to annotate your class types with the annotation below, and I'm sure everything will work out just fine for you..and your users, and those who have to maintain your code.

------
module test;

@BEWARE_all_code_in_this_class_is_a_c++_like_friend_of_this_class_including_unittests.
class Firefighter
{
    private void DoSomethingATraineeShouldNotDo() {}

}

class TraineeFirefighter : Firefighter {}

unittest
{
    TraineeFirefighter joe = new TraineeFirefighter();
    joe.DoSomethingATraineeShouldNotDo();

}
----------

On Monday, 29 April 2024 at 23:21:46 UTC, NotYouAgain wrote:
> ..
> ----------

"I have become more and more convinced that the key to code reusability and scalability is encapsulation — having subsystems communicate through small, well-defined interfaces and letting them hide their own implementation details."
- Walter Bright

http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394?queryText=Scott%2BMeyers

On Monday, 29 April 2024 at 23:31:55 UTC, NotYouAgain wrote:
>..

"The goal is to give the programmer the tools to do what he needs to do, rather than a bunch of red tape to dictate what he cannot do.  That's why we have @trusted, @system, and even asm.  The programmer is responsible for making sane architectural decisions with the tools he is given, rather than being told what (not) to do within the confines of his cell. "
- H. S. Teoh

https://forum.dlang.org/post/mailman.4716.1541041974.29801.digitalmars-d-announce@puremagic.com


private(this) is a tool for the programmer - a tool the D designers seems to insist he never gets his hands on. (or her, .., ...., if the case may be).

Why *so many* are **so strongly** against this particular tool, is rather bewildering.

Surely its not just because there is an alternative, but very burdensome tool available (the one-module per ..everything.. thing?

I think its more likely, there is some philosophical, principled postion they want to hang on to. Perhaps even something they really hate (like those that hate oop in general, and despise the fact the D says it supports it - I can point out some of those people if you want - one even inserted himself in this discuss, which ensured this discussion would go off track..yet again).

I cannot think of any other reasons for such strong, consistent, opposition.

On Monday, 29 April 2024 at 13:39:17 UTC, Basile B. wrote:
> ..
> ..
> Personally I casually use FPC, which has `strict private` (i.e `private(this)`) and `strict protected` (i.e `protected(this)`. I dont find them essential but as a matter of discpline I have used them a couple of time and found them to be useful, in certain cases. For example presentation and logic implemented in the same module, but be sure that the presentation will only use the getters/setters of the logic and not the fields.

The source of all this, can be trace back to the D designer who decided to change the "right and obvious" meaning of private.

That was a mistake. It's not the the moduleprivate is wrong, that certainly has a place, but changing the meaning of private, was a mistake that D has to live with.

As Chris Lattner (of Apple) said (in their discussions on fixing the exact same problem they had in Swift):

(1) "We keep public and private meaning the “right” and “obvious” things."

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html

It's time (a decade overdue actaully) for the D community to have this discussion.

Swift was already used widely when they made this change 8 years ago.

D is not in even widespread use today.

D could make the same change, and restore private to what everyone knows it to mean, and use moduleprivate or fileprivate as meaning private to this module.

Yes, I know the opposition to this idea. I do not need to here from them again. I'd rather here from those who support change, not those who are totally against it (as their views are already known).

That was the whole point of presenting this idea in the DIP ideas group, instead of the General group, where everyone piles onto you if you raise this idea.

On Tuesday, 30 April 2024 at 06:08:52 UTC, NotYouAgain wrote:
>

Interesting take on access (visibility) controls in Swift prior to Swift fixing this.

https://blog.human-friendly.com/swift-access-controls-are-like-cs-and-that-isnt-necessarily-a-bad-thing

The above blog was written before Swift 3 came out, which fixed private to mean what everyone had always expected it to mean.

D has the same problem. C like access control. .. and it's not surprising that Walter chose this, due to his very strong affinity with C.

But many Swift oop developers didn't like the C like access controls.

Swift designers fully understood and accepted the argument, the ack. the mistake they made, and they just fixed it.

Everyone is still happy using Swift, and Swift is a better language after the fix, than before it.