On Thursday, 23 June 2022 at 10:36:02 UTC, forkit wrote:
> On Thursday, 23 June 2022 at 10:34:50 UTC, Alexandru Ermicioi wrote:
>> On Thursday, 23 June 2022 at 10:16:42 UTC, forkit wrote:
>>>
>>> Coding style?
>>>
>>> Ummm .. no.
>>>
>>> Why is it, that some people ***still*** don't get it.
>>
>> I think that all people here get it. They don't agree on making an elephant out of mosquito.
>
> But it is an elehpant, not a mosquito.
>
> That's the point I've been trying to make - which it seems, is still not getting across to some.

Seriously, everyone here gets it. If they didn't before, they surely do by now. It's just that we disagree with you. That's it. And so far, you still haven't shown any real problem that `private(this)` solves.

Violation of encapsulation at the class boundary within the module *in D* is a conceptual problem. That's not true in other languages, but it's true here. That's because for the public API, where encapsulation actually matters in D, it happens at the module level.

I could go all "I can't understand why you don't get it", but I haven't gone there and I'm not going to. Fundamentally, you're refusing to accept that it isn't an elephant after all. And that's fine.

That's your prerogative. But please, just accept that we do understand you points and simply disagree with you. Repeating them endlessly isn't convincing anyone. If you want to convince someone, show us a real problem that `private(this)` solves *in D*.

And good luck! I'll keep an eye out for the post that gets there.

The longer I think about it (and that's really long, because of this thread), the more I dislike class private.
It's a bogus concept.
It make you think you have a strong type, but you can't prevent others from messing it up.

Maybe in very small projects (where it makes at least a little bit of sense to put everything in few files) it helps you to avoid making stupid mistakes (like using some private field in a function that shouldn't use it), but if the project grows the code must be re-organized anyway.
So it is much better to learn to do this from the start. And having one class in one file provides the same "protection" from stupid mistakes.

On Thursday, 23 June 2022 at 10:36:02 UTC, forkit wrote:
> But it is an elehpant, not a mosquito.

> That's the point I've been trying to make - which it seems, is still not getting across to some.

Well then you failed in your task. Perhaps changing the approach would help here.

I'd recommend to try and tone down a bit the emotions (aggressiveness mostly) in your posts, and provide enough evidence that it is indeed a problem, for people asking for proof (mostly bugs caused by having no private to class modifier).

Overall you did have some effect (this topic with restricted).

On Thursday, 23 June 2022 at 09:44:29 UTC, Dom Disc wrote:
>
> If you want your class to be encapsulated the same way, put it in its own module and make it read only.

...which resulted in unnatural duplicate names in symbol paths everywhere. Look at Tango, the glorious alternative D standard library, which tried to be classic Java-style OOP. Many (most?) classes there have paths like 'tango.io.device.Device.Device' (https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/io/device/Device.d). (yes, I know that in today's D you can use 'package.d' as a kludge to work around this).

On Thursday, 23 June 2022 at 10:29:46 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 23 June 2022 at 10:18:29 UTC, deadalnix wrote:
>> So there is a point at wish adding that expressivness is counter productive, it is at the point when the value of the extra things that you can express is lower than the cost incurred by implementing the change required for that extra expressivness to be possible.
>
> Yes, there is a cost if the syntax is messed up or if there is a breaking change.
>
> The cost for adding the feature is higher now than if one at a later stage choose to clean up the syntax (and thus get a breaking change anyway). So it probably should wait for a more general syntax cleanup.

D is already paying a big price, IMO.

If I look at the languages available, and the features they have that would enable me to do better software engineering, D would not even be on the list!

Swift would likely be no.1 - the 'choices' they offer to the programmer, are just superb!

I still think C++ got it right. I just wish they had GC, cause i got better things to do than worry about that crap these days. I actually like the C++ friends feature (although it's subject to misuse, like any feature really).

C# certainly high on the list.

But D.. nowhere to be found, in that list. Maybe on someother list.

On Thursday, 23 June 2022 at 10:50:30 UTC, Max Samukha wrote:
> On Thursday, 23 June 2022 at 09:44:29 UTC, Dom Disc wrote:
>>
>> If you want your class to be encapsulated the same way, put it in its own module and make it read only.
>
> ...which resulted in unnatural duplicate names in symbol paths everywhere. Look at Tango, the glorious alternative D standard library, which tried to be classic Java-style OOP. Many (most?) classes there have paths like 'tango.io.device.Device.Device' (https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/io/device/Device.d). (yes, I know that in today's D you can use 'package.d' as a kludge to work around this).

Imho package.d is not a kludge. Such approach is taken in typescript/javascript for example.

On Thursday, 23 June 2022 at 10:36:02 UTC, forkit wrote:
> But it is an elehpant, not a mosquito.
>
> That's the point I've been trying to make - which it seems, is still not getting across to some.

If it was an elephant, you'd have an abundant number of concrete exemple of problems caused by this.

You don't. So it's not an elephant.

On Thursday, 23 June 2022 at 10:34:53 UTC, forkit wrote:
> In C++, C#, Java, Swift, .... I have this choice, and my choice is to use it, and my software engineering is better because i make that choice. If it was useless, i wouldn't use it.
>
> In D, I don't have that choice.
>

You have this choice: put things in a different module.

On Thursday, 23 June 2022 at 10:50:26 UTC, Alexandru Ermicioi wrote:
> On Thursday, 23 June 2022 at 10:36:02 UTC, forkit wrote:
>> But it is an elehpant, not a mosquito.
>
>> That's the point I've been trying to make - which it seems, is still not getting across to some.
>
> Well then you failed in your task. Perhaps changing the approach would help here.
>

Well, my task, was to highlight this issue in D, and stop it from always being stuffed under the rug by the 'opposers'.

Thanks to dkorpel, for 'volunteering' his time and effort, to really move this forward (not as a new language feature, but as something you can try out, if you want).

So I'd say, the straedgy worked, just fine ;-)

Making 'noise' was, sadly, the only way to get any movement on this.

A DIP, at this point, would have resulted in absolutely nothing occuring. (probably why so many were encouraging me to take that path instead).

If anyone needs me, I'll be playing with 'private(this)' in dkorpel's branch of dmd.

On Thursday, 23 June 2022 at 11:04:40 UTC, forkit wrote:
> On Thursday, 23 June 2022 at 10:50:26 UTC, Alexandru Ermicioi wrote:
>> On Thursday, 23 June 2022 at 10:36:02 UTC, forkit wrote:
>>> But it is an elehpant, not a mosquito.
>>
>>> That's the point I've been trying to make - which it seems, is still not getting across to some.
>>
>> Well then you failed in your task. Perhaps changing the approach would help here.
>>
>
> Well, my task, was to highlight this issue in D, and stop it from always being stuffed under the rug by the 'opposers'.
>
> Thanks to dkorpel, for 'volunteering' his time and effort, to really move this forward (not as a new language feature, but as something you can try out, if you want).
>
> So I'd say, the straedgy worked, just fine ;-)
>
> Making 'noise' was, sadly, the only way to get any movement on this.
>
> A DIP, at this point, would have resulted in absolutely nothing occuring. (probably why so many were encouraging me to take that path instead).
>
> If anyone needs me, I'll be playing with 'private(this)' in dkorpel's branch of dmd.

So instead of just implementing it yourself, you had others do your work, and now you won't even go and write the DIP you were gathering opinions for. Good job....