February 09, 2023
On Thursday, 9 February 2023 at 22:34:29 UTC, ProtectAndHide wrote:
> On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:
>> On 2/8/23 04:07, zjh wrote:
>>
>> > Last time, someone proposed to add `private` like `C++'s`,
>>
>> We've discussed the 'private' topic very many times already. C++'s private necessitate the 'friend' keyword, which comes with it's own problems.
>>
>> Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way. Given the number of individuals who bring this topic up over and over up is so few that I don't think there is a common problem.
>>
>> Do you have actual bugs related to this? "Wanting" the inclusion of a feature is sufficient.
>>
>> In contrast, I use D every day and love its relaxed attitude towards private.
>>
>> > and then it
>> > was the same,they are always unwilling to add facilities
>> useful
>>
>> That is not correct. The truth is, nobody is jumping to implementations just because some people think they are useful. There are always valid reasons for including a feature or not.
>>
>> Ali
>
> You mentioned previously that D implements various things in unprincipled ways.
>
> I guess, if one wants to use D, one has to be comfortable with this.
>
> But using a relaxed attitude towards the implementation of such a common and important abstraction, that in turn allows me to so easily shoot myself in the foot, is not really an attractive feature .. to me ;-)
>
> btw. When a newbie to D raises ideas, suggestions, etc... and you counter them with (in essence) 'we don't need that in D, but go write a dip if you think we do' attitude, is a real turn off.




Most of the time, when people use "private", they are actually shooting their users which can't even extend their class. I rarely see code which people use "protected" instead and I find that pretty lacking. One thing is hiding memory allocation details on your class, other thing is hiding a property which could and should be controlled when extended in a class.

To be fair I'm more often than not against private variables. Most of the time it only caused me headaches because there was a lot of unimplemented features and I could not simply fork the project. This is not only in D. I got that in Java, Haxe, C#. Thankfully those languages has ways to simply ignore the private attribute, which can't be done in D.

Anyway, I'm not against static classes and I don't think they would bring any inherent problems, they should not cause regression and they should be easy to implement as the compiler already has the tools for it
February 09, 2023
On 2/9/23 14:34, ProtectAndHide wrote:

> You mentioned previously that D implements various things in
> unprincipled ways.

I think you will continue misunderstanding that term. What it means is, D does not insist on certain programming paradigms over others. For example, you can code in structured, functional, object-oriented, etc. styles depending on your problem.

> I guess, if one wants to use D, one has to be comfortable with this.

I can't see how being free is something that one needs to be comfortable with but I guess you are correct.

> But using a relaxed attitude towards the implementation of such a common
> and important abstraction, that in turn allows me to so easily shoot
> myself in the foot, is not really an attractive feature .. to me ;-)

Thanks for the wink.

> btw. When a newbie to D raises ideas, suggestions, etc... and you
> counter them with (in essence)

That is not the essence at all! There has been numerous responses here before I reminded how the path is actually open for language changes.

> 'we don't need that in D, but go write a
> dip if you think we do' attitude, is a real turn off.

What was the alternative? Jumping to implementations of all suggested features? A bigger turn off would be forkit!

Ali

February 09, 2023
On Thursday, 9 February 2023 at 19:17:15 UTC, Adam D Ruppe wrote:
> On Thursday, 9 February 2023 at 13:00:04 UTC, thebluepandabear wrote:
>> For my school I am commissioned to create many types of software. I tried to have a look at some of the gui kits in D but there was no tutorial for how to use them and they seemed as if they are lacking features in comparison to Qt/JavaFX.
>
> So your objection is one of newbie documentation. That's fair. Qt I always thought had nice docs, they're hard to beat. I've been slowly adding more to my stuff but it is a slow process.
>
> idk about features though, you saying "seemed" means you probably don't even actually know what they have so that's not as actionable.

it's not anything personal, it's just that the current gui libraries for D are only around 1/100th of the size of other ones such as Qt/JavaFX, it's not really on the same wavelength, and there's nothing wrong with that specifically, it's very difficult to make an enterprise level gui library from scratch
February 09, 2023
> btw. When a newbie to D raises ideas, suggestions, etc... and you counter them with (in essence) 'we don't need that in D, but go write a dip if you think we do' attitude, is a real turn off.

yeah it seems like the community is closed off for feedback, which is concerning. namespaces/static classes are a net positive for the language, and they've been shown to be an extremely good features, being implemented in Kotlin, C#, and C++.

if the language wants to gain more people it needs to evolve
February 09, 2023
> In contrast, I use D every day and love its relaxed attitude towards private.

the fact that private stuff is accessible from other classes in the same module is really really bad, and it's pretty detrimental to the language.

let's actually think about what `private` means.

when you come back from work, arrive home, and you close the curtains and want some alone, you want to be private to everyone.

you wouldn't want your neighbours (the module) to peek at what you're doing.

your neighbours aren't your friends in real life, and they (the module) aren't your friends in code -- just because they are in your vicinity doesn't mean they have a right to violate your privacy.

tbh this whole private behaviour should be changed, it's just so weird
February 09, 2023
On Thursday, 9 February 2023 at 23:13:00 UTC, Ali Çehreli wrote:
>
>...

Well, the only thing we can say for sure now, is that since 'class', 'oop', and 'private' have all been mentioned in this thread, some 'key D people' (wink wink) will come out to derail this thread by further pointing out how D neither needs (nor wants) any of these things... and that real programmers shouldn't need them either.

So I hand that over to you .. wink wink.

February 09, 2023
On 2/9/23 15:58, thebluepandabear wrote:
>> In contrast, I use D every day and love its relaxed attitude towards
>> private.
>
> the fact that private stuff is accessible from other classes in the same
> module is really really bad, and it's pretty detrimental to the language.

Not everybody shares that view. So, there must be something deeper here: maybe some people are blind (including me), or others have expectations that they carry from other languages, or something else... But look at the contrast: Some people see the same thing as great and some people see it as really really bad.

One thing is clear: We can't agree on this topic at least at this time.

> let's actually think about what `private` means.

It gives implementation freedom: I can change my implementation at will.

The same exact goal can be achieved by convention as well: I can name my members with e.g. an underscore and everybody understands that they are private. Nobody touches it and they are protected from future implementation changes.

If they do, they do it with full understanding that their code may break in the future.

> when you come back from work, arrive home, and you close the curtains
> and want some alone, you want to be private to everyone.

I don't agree with that example: Yes, it's the same word but different meanings in code.

> you wouldn't want your neighbours (the module) to peek at what you're
> doing.

Yes but I would have no problem other code looking at or using parts of my code if they wanted to.

> your neighbours aren't your friends in real life,

There is some friendship with my neighbors! :)

> and they (the module)
> aren't your friends in code

Some of them are and some aren't.

> -- just because they are in your vicinity
> doesn't mean they have a right to violate your privacy.

Right to violate doesn't mean anything will be broken. It means, there will be no hurdle if access is needed. Nobody will or does violate anything. I haven't seen a single time when D's approach to privacy caused harm.

> tbh this whole private behaviour should be changed, it's just so weird

Ok, I like "so weird" more than "really really bad". :)

Ali

February 09, 2023
On 2/9/23 15:59, ProtectAndHide wrote:

> some 'key D
> people' (wink wink)
[...]
> So I hand that over to you .. wink wink.

You're trolling[1] again.

Ali

[1] https://www.merriam-webster.com/dictionary/troll#h3

February 10, 2023

On Thursday, 9 February 2023 at 23:51:18 UTC, thebluepandabear wrote:

> >

btw. When a newbie to D raises ideas, suggestions, etc... and you counter them with (in essence) 'we don't need that in D, but go write a dip if you think we do' attitude, is a real turn off.

yeah it seems like the community is closed off for feedback, which is concerning.

Not at all. These things have been discussed to death and decisions have been made. Do you regularly have discussions with the folks in charge of Java, C#, or C++? Do they quickly implement your requested features?

>

if the language wants to gain more people it needs to evolve

I doubt that this would lead to a large influx of new D programmers. It would more than likely make the language more complex and less desirable, reducing the number of users.

February 10, 2023

On Friday, 10 February 2023 at 00:18:59 UTC, Ali Çehreli wrote:

>

On 2/9/23 15:58, thebluepandabear wrote:

> >

In contrast, I use D every day and love its relaxed attitude
towards
private.

the fact that private stuff is accessible from other classes
in the same
module is really really bad, and it's pretty detrimental to
the language.

Not everybody shares that view.

Correct. I think D has made the right decision, even if others want it to be what they're used to, and even if they have never bothered to try an alternative approach. In the many discussions on this, I have only seen opinions and conjecture, never a strong argument for a change.