On Wednesday, 22 June 2022 at 05:48:22 UTC, Ola Fosheim Grøstad wrote:
> 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».

I don't argue that class default should be private.

I think most D programmers, would not appreciate this ;-)

I'd like it to be sure. I wish it was when D was designed.

But I'm not arguing for that now. A future version, maybe, if a majority decide that.

As far as defaults are concerned, valid arguments for both module-private and class-private can be presented. The Swift community also undertook discussions related to this, and they decided internal *was* the appropriate default for them. But Swift (rightly) allows programmers to have finer grained control over the class type (and others actually) including fileprivate, and private (like C++, C#.. god.. even Javascript now!).

But I am unaware of any argument, related to OOP and classes, where not having a language 'option' for declaring a member of a class as private, has provided a benefit to software engineering. I am fully aware of arguments in the other direction however ;-)

There is no such thing as a workaround here.

Any solution needs to ensure type safety, by (at least) having the compiler statically enforce it.

I'd love to get Bjarne Stroustrup, Anders Hejlsberg, Mads Torgersen, James Gosling and Chris Lattner, in a virtual meeting, and ask them this question:

"Do you think a class type should be able to declare members to be private?"
"Do you think such a declareation should be statically enforced by the compiler?"
"What do you think about the D Programming approach, of now giving the programmer that option?"

On the last question, I doubt I would get a response. Just a smirk from each of them ;-)

On Wednesday, 22 June 2022 at 06:49:01 UTC, forkit wrote:
>
> "What do you think about the D Programming approach, of now giving the programmer that option?"

oops:

"What do you think about the D Programming approach, of NOT giving the programmer that option?"

On Wednesday, 22 June 2022 at 07:41:51 UTC, Ola Fosheim Grøstad wrote:
>
> Well, you can do what I did. Create a fork, add a modified parser that is run on files with a different filename extension (like "file.d3").
>

I do have my own fork (local, not git).

I've made some minor changes here and there over time.

I only use my fork. I think its the version right before ImportC was added ;-)

>
> This is stuff that is easy to add yourself.

easy for some ;-)

> Stuff like type system support for memory management is more critical at this point in time.
>

Even if a DIP were successful, I would not expect it to be prioritised over more pressing matters.

Additionally, since its a volunteer commmunity, people will choose what they want to work on - so someone would actually have to 'volunteer' to implement it. I doubt that would be Walter, and in any case, he certainly has enough on his plate... for the forseeble future.....

So passing a DIP, and having it implemented, are two **very completely different** things. Let's not conflate them.

On Wednesday, 22 June 2022 at 08:00:41 UTC, claptrap wrote:
>
> ...

see. i knew there were some anti-OOP in the D community.

thanks for the 'data' ;-)

On Wednesday, 22 June 2022 at 08:00:41 UTC, claptrap wrote:
>
> Lets be honest there's no data that adding "class private" would prevent bugs or cure cancer. Just a couple of people waving their arms because somebody told them the world aint flat like the good book of OO told them and now they cant cope.
>
> The nearest thing to data we have is that the vast majority of experienced D users dont give two hoots about it and the only people who do get upset are the occasional newbie every 6 months or so.
>
> Maybe go through github / bugzilla whatever, find some **real** examples of bugs it would have prevented. I think you'll have a tough time, because if it did help prevent bugs more people would be like "oh yeah that would be really useful".

So your agrument then, is less abstract data type cohesion and greater coupling will improve OO software engineering?

On Wednesday, 22 June 2022 at 08:00:41 UTC, claptrap wrote:
>
> Lets be honest there's no data that adding "class private" would prevent bugs or cure cancer. Just a couple of people waving their arms because somebody told them the world aint flat like the good book of OO told them and now they cant cope.
>
> The nearest thing to data we have is that the vast majority of experienced D users dont give two hoots about it and the only people who do get upset are the occasional newbie every 6 months or so.
>
> Maybe go through github / bugzilla whatever, find some **real** examples of bugs it would have prevented. I think you'll have a tough time, because if it did help prevent bugs more people would be like "oh yeah that would be really useful".

Controlling the Use of Information
------------------------------------
"... In this section we discuss the benefits that accrue
from this limitation: the programs which result are more
modular, and easier to understand, modify, maintain and
prove correct."

Liskov and Zilles, 1974

https://dl.acm.org/doi/pdf/10.1145/942572.807045