Extending D's support for object-oriented design with private(this)

[Jonathan M Davis]

On Saturday, April 27, 2024 2:39:50 AM MDT NotYouAgain via dip.ideas wrote:
> You (and others) provide alternatives to private(this) when
> people discover those problems, but you (and others) don't see
> what the problem identified, as a problem, but as a non-problem,
> but still, one requiring a solution? I don't get the logic in
> that.
>
> If there is no problem, why propose the one class per module, one
> unittest per module, solution?

No, all we're saying is that if you think that it's a problem for the module
to be treated as the unit of encapsulation, you can have one class per
module to get around that. We're not arguing that that's actually how you
should be writing your code. How you organize it is up to you. Many of us
put quite a few types and functions in the same module and have no problem
with it, but we're also not determined to view the class as the unit of
encapsulation.

> Yes. I know the argument. C++, C#, Java, Swift, Javascipt,
> Haskell...etc. programmers are the actual problem, not D. They
> come to D expecting the wrong thing..It's their thinking that is
> the problem, not D.
>
> That's not a convincing argument. Never has been. Never will be.
>
> private(this) and the problem is no longer there. All those
> programmers will not be required to change how they think. D
> might even become popular then.

Ultimately, D chose to go the route of making the module the unit of
encapsulation. Some people don't like that (usually because that doesn't fit
with how they want to view OOP), but it's served us well overall, and it's
allowed us to have a simpler situation with regards to visibility attributes
than some other languages have. Adding an extra layer to it to allow classes
to be treated as a unit of encapsulation might satisfy those who want to
insist that the unit of encapsulation should be the class for proper OOP,
but in practice, it hasn't been necessary for D.

Obviously, it's a design decision with tradeoffs, as most design decisions
are, and some people aren't going to agree with it, but it is one that has
worked quite well for us overall.

You're free to hate that decision. You're free to propose a change to the
language like you're doing to try to get the situation to change. Sometimes,
Walter agrees to make a change, and sometimes he doesn't. So, if you're
convincing enough, maybe the situation will change, but based on what he's
said about this in the past, I fully expect that it will be rejected.

When learning any language, it's bound to be the case that some design
decisions of the language do not match what you expect or want. Sometimes,
it's because those decisions are bad. Sometimes, it's simply because it's
not what you're used to or because it doesn't fit how you want things to
work. In some cases, it's something that you ultimately come to agree with
and like, whereas in other cases, it's just a part of the language that's
permanently annoying. You (and anyone else coming to D) will come to your
own conclusions about where D's view on private and the unit of
encapsulation falls on that scale.

So, no, I'm not going to argue that C++ or C# or whatever did it wrong. I'm
just going to say that D made a different design decision, and it's one
that's worked well for us. And assuming that you don't convince Walter to
change the language, you'll have to figure out how to best work with how
private works in D for as long as you choose to use D. Ultimately, whether D
did it better or not, D did it differently, and everyone using D has to deal
with how it works. For anyone who insists on treating the class as the unit
of encapsulation, it's likely to be annoying, whereas for anyone who's
willing to treat the module as the unit of encapsulation, it works quite
well.

- Jonathan M Davis