`restricted` member variables

[forkit]

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.