On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:
> Data hiding is overrated.
> Furthermore, OOP is overrated :-)
>
> https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7

Submit a request to the C++ Committee to remove private from the language.

Do the same for C#

Do the same for Swift

Do the same for Javasript...

Then watch how they all ridicule you for presenting such an absurd proposal ;-)

Oddly enough, then you will know how I feel when I'm ridiculed for advocating that D adds a private-like declaration for the type - something all those languages have, and the majority of the programmers in those languages would be using on a regular basis.

As for OOP being overrated, I don't necessarily disagree ;-)

But OOP is a tool that works well, when that tool is the best tool for the job.

On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:
> Data hiding is overrated.
> Furthermore, OOP is overrated :-)
>
> https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7


What is 'Object-Oriented Programming'? (1991 revised version) Bjarne Stroustrup

https://www.stroustrup.com/whatis.pdf

On Friday, 17 February 2023 at 06:56:08 UTC, ProtectAndHide wrote:

> What is 'Object-Oriented Programming'? (1991 revised version) Bjarne Stroustrup
>
> https://www.stroustrup.com/whatis.pdf

Thirty years passed since. Lessons were learned. Out of three PLs of the newer generation (Rust, Swift, Go), two are not OOP, basically.

And no private/public/protected:
https://doc.rust-lang.org/reference/keywords.html
https://go.dev/ref/spec#Keywords

:-P

Funny, seems I have old news: Rust adopted D-like module visibility.

https://doc.rust-lang.org/reference/visibility-and-privacy.html

pub(in path), pub(crate), pub(super), and pub(self)

In addition to public and private, Rust allows users to declare an item as visible only within a given scope. The rules for pub restrictions are as follows:

pub(in path) makes an item visible within the provided path. path must be an ancestor module of the item whose visibility is being declared.
pub(crate) makes an item visible within the current crate.
pub(super) makes an item visible to the parent module. This is equivalent to pub(in super).
pub(self) makes an item visible to the current module. This is equivalent to pub(in self) or not using pub at all.

On Friday, 17 February 2023 at 09:56:26 UTC, RTM wrote:
> On Friday, 17 February 2023 at 06:56:08 UTC, ProtectAndHide
>
>
> Thirty years passed since. Lessons were learned. Out of three PLs of the newer generation (Rust, Swift, Go), two are not OOP, basically.
>
> And no private/public/protected:
> https://doc.rust-lang.org/reference/keywords.html
> https://go.dev/ref/spec#Keywords
>
> :-P

this is not a discussion about one paradigm or language being better or worse than another.

btw. neither Rust nor Go claim to support OOP. They don't even have a class type.

so it doesn't suprise me they don't have a language mechanism for class-type privacy.

for OOP using classes, the class designer should be able to expose only that which should be exposed, and no more. in D, everything is exposed inside the module, and the only solution D provides to prevent this, is to not put any other code in the same module as that class - this includes not putting your unittests in that module either.

please compare apples with apples, not apples with sardines ;-)

On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:
>
> Data hiding is overrated.
> ...

Actually, data hiding is at the core of using objects, and objects are at the core of doing OOP.

" Hiding internal state and requiring all interaction to be performed through an object's methods is known as data encapsulation — a fundamental principle of object-oriented programming."

https://docs.oracle.com/javase/tutorial/java/concepts/object.html

D can 'provide' that encapsulation. That is true. But it does it **indirectly**, by requiring the class representing that object to not have any other code in the module containing that class. If there is any other code in the module with that class (including unittests), then that class is no longer encapsulated.

There should be no argument as to whether the statements above are correct or not. They are clearly correct.

The only objection people can reasonably raise, is whether its ok to provide encapsulation in this manner (i.e. indirectly), or whether the language should provide a mechanism whereby the progammer can 'declare' the encapsulation.

It should not come as a surprise, given C++, C#, Java, Swift, Javascript.. .. ... that a programmer might want to have more explicit access control... since they have it in those languages ... and those languages represent the vast majority of the worlds programmers.

What is surprising, is the level of objection in the D community to allow such an option in D.

Since the majority of programmers in the world HAVE this option already, there will be continued debate over this issue, should they ever come and have a look at D. That much is certain.

But the debate should not be about whether a programmer needs to encapsulate their object. That is a choice the programmer should make. It's a design decision for them, not for others.

The debate should be whether those programmers should be FORCED to put each and every class in its own modules. That's a design being forced on the programmer in order to get encapsulation of that object.

D forces a 1:1 mapping of class to module in order to provide object encapsulation. That is what I don't like. Keep in mind, this also means unittests must be in a separate module as well, as the unittest in the same module as the class, means the class is no longer encapsulated (i.e. the compiler cannot assist you - in relation to type safety - when you accidently reference a private member - which is what I did when I first came to D - and hence, is the reason for my raising this as an issue in the first place).

I think this thread has lost any usefulness, because many try redirect the issue at hand to something else completely. But this post summarises the problem well enough for everyone to understand - and choose their side ;-)

On Friday, 17 February 2023 at 22:58:19 UTC, ProtectAndHide wrote:
>

Actually, I just now understand 'why' (as opposed to 'how') private works in D the way it does.

In D, private within a module is (more-or-less) like static used in C outside of a function.

That is, in C it restrains the visibility to the current file, and so it does in D (visibility to the current module).

ok fine. That works well in C.

But C does not have classes! (user defined types with their own abstraction boundaries).

So what would happen if C got classes then?

Well, we already know -> C++ (private declared within a user-defined type, restrains visibility to that type). And so it does in C#, Java, Swift, Javascript .. ... ....

So in essence, the D module is still stuck in the C era it seems.

Now I'm fully convinced that OOP should never, ever, ever, be done in D.

Now I can finally move on ;-)

On Saturday, 18 February 2023 at 06:12:47 UTC, RTM wrote:
>
>
> No offense, but it looks like your surprise comes from your inexperience.

More likely is comes from my experience .. otherwise I wouldn't be surprised ;-)

btw.

I love the way that Brayan Martinez (Senior Developer with Azure, Spring Boot, and Flutter.) outlines all the well-thoughout out positive reasons.
https://github.com/dart-lang/sdk/issues/33383#issuecomment-395987115

Then the next guy says..."Sounds like personal preference."
https://github.com/dart-lang/sdk/issues/33383#issuecomment-396031405

As for me, I don't even know what Dart is ;-)

I guess we could all revert to:

class foo()
{
  int _x; // this is private. please don't use it outside of this class.
}

and hope that people read and comply with that instruction - cause we all know how great people are at following instructions ;-)

D could just add a new keyword (problem solved!)

class foo()
{
  intern int x; // x is internal to foo.
}

of course, then we get to the next issue ... protected ;-)

No, I think D is not for me.