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

[Jonathan M Davis]

On Saturday, April 27, 2024 1:12:16 AM MDT NotYouAgain via dip.ideas wrote:
> On Saturday, 27 April 2024 at 06:48:47 UTC, Jonathan M Davis
>
> wrote:
> > ..
> > ...
> > ... So, from my perspective, you're trying to solve a problem
> > that isn't even a problem in the first place.
>
> Mmm. This is where you don't understand my motivation.
>
> I'm not saying that it's causing widespread problems and that it
> needs to be addressed.
>
> I'm saying, I want to prevent the problem from even occuring.
>
> Almost any newcomer to D, will experience this problem.
>
> There is no solution to them, other than to 'be more careful', or
> put the class in a module by itself, and ensure any unittest
> testing it, is also in another separate module. In that is
> solution being proposed to 'prevent' the problem'.
>
> My proposal is more likely be used, as it's so much easier.
>
> You present the hard solution to preventing the problems, I
> present the easy solution.
>
> If I understand correctly, that seems to be where we differ.
>
> You saying -> be careful not to do it so that it doesn't cause
> problems, or put use separate modules for everything.
>
> Me saying -> use private(this)
>
> A class is 'a type' of a particular thing, describing its
> properties and how it is to be interacted with, just like
> anyother type. If people come to D with that mindset, they will
> make mistakes, just like most newcomers make that mistake.
> Forcing them to think of the class as a subtype of the module, is
> not going to work. They'll just go elsewhere (which may well me
> the desriable outcome for some ;-)

What I'm saying is that there isn't actually a problem that needs solving.
It's a theoretical issue and not one in reality. Programmers routinely
program in D without running into any issues with private. Some of them even
think that private is private to the class or struct and are surprised years
later to find out that it isn't, because they never have problems with it.

Visibility attributes are necessary for controlling the public API, which
D's private does just fine. From what I've seen, the only problem that we
actually get from it is people being surprised that D's private is private
to the module and then who want it to work differently (or who want
something like private(this) in addition to private), because they think
that it's good OO programming to have that and that it's dirty otherwise.
But from a practical standpoint, I'm not sure that I've ever seen a bug
reported that happened because private was for the module and not the type.
If anything, the odds have been much higher that there's a compiler bug that
has accidentally made something public or private when it shouldn't be
(particularly since the change from private, public, etc. being protection
attributes to visibility attributes seems to have been tricky enough that a
number of subtle bugs were introduced in the process).

In my experience, there simply isn't anything to worry about here, and
usually, the folks who are worried about it are worried about it because
it's not what they're used to or because it doesn't fit in with their ideal
view of OO programming. It is a topic that I've seen come up periodically
over the nearly twenty years that I've been using D, so it's far from new,
and it will probably never go away as long as things stay the way that they
are, but it's almost always newcomers complaining because it's different and
not people who have actually had problems who complain. And in general,
folks who program with D the way that it is find that private works just
fine as-is. Other aspects of the language may cause problems, but private
being private to the module really hasn't been causing problems in general.

So, yes, I bring up moving code to other modules as a solution if you
actually want to guarantee that it doesn't have access to the code in the
module that it was in, because that will give you that guarantee. But it's
not something that I'm arguing that folks should be doing as best practice,
because it simply isn't necessary in practice.

And because I have not seen anything that private(this) is trying to solve
as something that's actually causing problems, I don't see any reason to add
a language feature to try to solve those problems.

- Jonathan M Davis