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

[Jonathan M Davis]

On Friday, April 26, 2024 11:44:15 PM MDT NotYouAgain via dip.ideas wrote:
> On Saturday, 27 April 2024 at 01:41:54 UTC, Jonathan M Davis
>
> wrote:
> >..
> >
> > ...
> > - Jonathan M Davis
>
> As usual, the only solution you can provide to the problems that
> I've very clear outline, are put the class in it's own module.
>
> That is the only solution to the problems.
>
> You say that all that D needs to do.
>
> I say, no, make it easier for me to solve my problems.
>
> A class already has a boundary outside of a module.
>
> Why you so determined to ensure a programmer never has the option
> of explicately declaring that boundary to other code in the
> class. I just don't get it. I can only presume you don't to oop,
> or you put every class in its own module, and every unittest for
> that class its own module as well.
>
> Well, no. There is an easier way -> private(this).
>
> No impact at all on existing code as far as I can tell. It's
> purely optin.
>
> But I think you're determined to think the same way - in the same
> way that you tell me that I'm determined to think the same way ;
>
> I've presented a number of examples now, where private(this)
> solves the problem identified.
>
> You're solution is one class per module, no unittest in the
> module either.
>
> No. I don't accept this as a good solution to the problems I've
> indentified.

No. I simply don't buy that any of the issues that private(this) is trying
to solve are problems in practice.

I have never found it to be difficult to reason about a class or struct just
because there's other code in the module which could access the private
members of that class or struct. And accessing private members by accident
is not something that happens often if ever in my experience. If anything,
it's usually a complete non-issue even if the code does access private
members, because it's all code under the control of the maintainers of the
module and has no effect on the public API.

And in plenty of cases (especially unit tests), it's actually desirable that
other code within the module be able to access the private members. The
whole point is to prevent code from outside the module from accessing the
private data, and it usually doesn't matter if other code within the module
does. And if it is actually a problem, then you can put the code in another
module, much as that's obviously not the answer that you want. But in my
experience, I simply don't have problems with code accessing private data
when I don't want it to. Maybe that's in part due to the fact that I
typically name private members differently from public ones by prepending
them with an underscore, so it's very obvious which I'm using, making it
rather hard to use the wrong one by accident, but I simply don't run into
problems where having member variables be private to a module instead of to
the class or struct is the cause.

So, I don't disagree with you that private(this) solves the issues that
you're worried about. I disagree that the issues are significant enough that
a language change is required.

I routinely put several types and functions within a module and put the unit
tests in the same module right next to the code that they're testing, and I
don't run into issues with private as a result of that. Plenty of other D
developers have the same experience. So, from my perspective, you're trying
to solve a problem that isn't even a problem in the first place.

In addition, mucking around with the implementation for private will almost
certainly result in bugs added to the compiler, because that happens pretty
much every time that the visibility attributes get mucked with. It also
raises issues of what happens with __traits(getVisibility, ...), and it
would presumably mean adding another string to the list, making it yet
another thing that code doing type introspection potentially has to take
into account. I'd rather not have to deal with that either.

Now, you clearly feel that there's a problem that needs solving and that
private(this) will solve it. Some folks agree with you. And there's nothing
wrong with bringing up the idea and trying to talk Walter into it. But I
don't personally think that there's a problem that needs solving here or
that adding the extra complication to the language that it would entail
would be worth it. So, that's really our disagreement here rather than
whether private(this) solves what you're trying to solve.

I'm also quite sure that unless something you say manages to change Walter's
mind, he will have a similar opinion to mine, because that has consistently
been his opinion on this topic for years now. But we'll see what he says
when he voices his opinion about your specific proposal. Much as I expect
him to reject it, I would say that your odds are probably slightly better
with adding private(this) than they would be with trying to get him to
change what private means.

- Jonathan M Davis