June 21, 2022

On Tuesday, 21 June 2022 at 12:33:13 UTC, deadalnix wrote:

>

On Tuesday, 21 June 2022 at 11:06:17 UTC, bauss wrote:

>

D will do anything to not have class private.

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.

Like I've mentioned before I have no problem with module private, I just think it would be a nice-to-have.

It's not a deal breaker for me that D doesn't have it, but I do see the value in it.

So far I've been doing fine the past decade without and I reckon I will be doing fine regardless of whether it is added.

June 21, 2022

On Tuesday, 21 June 2022 at 12:33:13 UTC, deadalnix wrote:

>

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.

You don't have any data to substantiate "much more useful", do you?

June 21, 2022

On Tuesday, 21 June 2022 at 12:53:06 UTC, Max Samukha wrote:

>

You don't have any data to substantiate "much more useful", do you?

Unfortunately, this answer did not convince me that something needs to be changed.

June 21, 2022

On Tuesday, 21 June 2022 at 13:50:35 UTC, deadalnix wrote:

>

On Tuesday, 21 June 2022 at 12:53:06 UTC, Max Samukha wrote:

>

You don't have any data to substantiate "much more useful", do you?

Unfortunately, this answer did not convince me that something needs to be changed.

Is anyone here actually advocating to redefining private here? I don't see why are you so opposed to optional features, unless there some major drawback that outweighs the benefits that I am unaware of?

-Alex

June 21, 2022

On Tuesday, 21 June 2022 at 19:27:10 UTC, 12345swordy wrote:

>

On Tuesday, 21 June 2022 at 13:50:35 UTC, deadalnix wrote:

>

On Tuesday, 21 June 2022 at 12:53:06 UTC, Max Samukha wrote:

>

You don't have any data to substantiate "much more useful", do you?

Unfortunately, this answer did not convince me that something needs to be changed.

Is anyone here actually advocating to redefining private here? I don't see why are you so opposed to optional features, unless there some major drawback that outweighs the benefits that I am unaware of?

-Alex

That's my thinking. I really don't care about a war of debates. I need specific tools. I've already illustrated that it's a useful, fundamental construct that I use.

  • If someone can give me a 10 line patch to DMD that adds it, I'll use that fork from now on.

  • If someone can give me a optional compiler switch, I'll use that from now on.

  • If someone can give me a DScanner modified tool that scans for private violations but the compiler ignores it. I'll use that.

D isn't my baby. It's my tool.

I mean, we might as well flip it around and use these same arguments for the opposite. Why allow modular level private? If you're "git gud" programming, you shouldn't NEED modular private! Modular private is just a crutch for bad programmers that prevents you from expanding existing code, and D is all about expanding code.

And 'tossing literally every class into its own file' just to add private is an incredible statement. Oh yeah, let me toss up another 300+ files instead of organizing my project files based on topic and role, I'll just have an extra 300 files all over the place and have to deal with every single class being in its own namespace instead of having any benefit of shared namespaces. And I'm not crapping on whoever suggested it, it's just like we live in different worlds for you to even suggest that.

I'm trying to make games here, and I've already illustrated how that's apart of my rapid dev process. Make code work, then make it correct, and private is tool for lopping off sections of code and dealing with them.

Maybe private isn't needed for "D is just a shell scripting language" projects. But in a real codebase, private is typesafe documentation. It's a compiler-checked indication of correct usage. You may remember all the bells and whistles of 'best case usage' of your code today, but in two months you won't.

If I come off as overly harsh, I apologize, that's just how I communicate and it's not meant as a direct insult.

June 21, 2022
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.

June 21, 2022
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.
June 22, 2022
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.

June 22, 2022

On Wednesday, 22 June 2022 at 00:32:59 UTC, forkit wrote:

>

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.

Yes, it is indeed true that class private ought to be the default, but in the meanwhile you can use a convention like prefixing with underscore.

It is a bit ugly, but not more ugly than «scope private» or «class private».

June 22, 2022
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.