On Tuesday, 21 June 2022 at 12:33:13 UTC, deadalnix wrote:
>
> To the contrary, it doesn't have that today and is doing nothing.
>
> If you want it to do something, you need to justify that it is worth doing.
>
> So far, all we got is "This is mandatory as per my definition of OOP", which is not a convincing argument.
>
> This is especially not convincing because many people here have been using D for many years, and most of them had a "hu, that's weird" moment when they figured out how private was working. And then figured out that the current behavior is actually much more useful in practice.

Well, i was going to limit myself to only one post.. but you're comment requires a rebuttal ;-)

As an OO programmer for over 20 years (and before that a C/C++ programmer for a short period), I can tell you defintively, that D turning a 'class' type into a 'doWhatEverTheFu%#YouWantWithMe' type, is not acceptable to me, as a programmer.

That I need to 'justify' to the D community, as to  why I would want an 'option' to declare private members inside my class.. really.. it's a complete joke.

It's a even bigger joke, that you can't all see that it's a complete joke.

C like procedural programming is fine in D (it's really what it does best).

I've been 'playing' with D for what... 6 years now I think....I have a LOT of code in D...but not once have I ever been tempted to do OOP in D. And I never will.

Other languages understand the concept of the class type.

I mean shit, even Javascript gets it (and that's not even a language! .. but I digress.

https://hacks.mozilla.org/2021/06/implementing-private-fields-for-javascript/

You may retort, i know you will. but my point is made, and I need not clarify it any further in this thread.

On Tuesday, 21 June 2022 at 22:29:13 UTC, forkit wrote:
> Well, i was going to limit myself to only one post.. but you're comment requires a rebuttal ;-)
>
> As an OO programmer for over 20 years (and before that a C/C++ programmer for a short period), I can tell you defintively, that D turning a 'class' type into a 'doWhatEverTheFu%#YouWantWithMe' type, is not acceptable to me, as a programmer.
>
> That I need to 'justify' to the D community, as to  why I would want an 'option' to declare private members inside my class.. really.. it's a complete joke.
>
> It's a even bigger joke, that you can't all see that it's a complete joke.
>
> C like procedural programming is fine in D (it's really what it does best).
>
> I've been 'playing' with D for what... 6 years now I think....I have a LOT of code in D...but not once have I ever been tempted to do OOP in D. And I never will.
>
> Other languages understand the concept of the class type.
>
> I mean shit, even Javascript gets it (and that's not even a language! .. but I digress.
>
> https://hacks.mozilla.org/2021/06/implementing-private-fields-for-javascript/
>
> You may retort, i know you will. but my point is made, and I need not clarify it any further in this thread.

Considering you failed to point at any concrete problem caused by that design decision, I'll now have to increase my confidence in the fact that there is none.

After, if there were, you'd have stated them.

On Tuesday, 21 June 2022 at 23:59:03 UTC, deadalnix wrote:
>
> Considering you failed to point at any concrete problem caused by that design decision, I'll now have to increase my confidence in the fact that there is none.
>
> After, if there were, you'd have stated them.

Well i had a thread where all these things could have been discussed ;-)

One of the 'biggest' selling points of D (certainly for me), was it's syntax being compatible with the syntax of the languages whose developers D was targetting. That was a good decision, and has really paid off, no doubt about it.

But as to why Walter then decided to completely change the concept of class, for those same programmers, has, and always will be, a pain point for D  - and that continues to be self-evident, from at least 2004.

It's much easier to learn new syntax, than changing (and especially being forced to change), a concept that has been the same...for decades...

To me, members of a class should be private by default, but you should have the option to make some public (and indeed, you need that option). I'd anticipate that *most* programmers would agree.

But the idea that member of a class must be ALWAYS public, is just crazy nonsense! That's not a class type, that's a 'doWhatEverTheFu%$YouWantWithMe' type.

If you don't get that, you should not be programming.

As Walter has pointed out himself, the one-class-per-module is an unreasonable constraint to impose on a developer.

https://forum.dlang.org/post/pr110b$9j5$1@digitalmars.com

The only discussion worth having about this, is the technical aspects and consequences of implementing such an option (i.e. should it be soft-private or hard-private, for example.).

The discussion as to whether its even worthwhile to allow 'an option' for members of a class to be private, is senseless. Every programmer should already know the benefit of having private class members.

On Tuesday, 21 June 2022 at 23:59:03 UTC, deadalnix wrote:

> Considering you failed to point at any concrete problem caused by that design decision, I'll now have to increase my confidence in the fact that there is none.

It's interesting how you are at the same time denying the problem exists and offering a kludge to solve it. )

>
> After, if there were, you'd have stated them.