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

[NotYouAgain]

On Thursday, 25 April 2024 at 19:48:11 UTC, Jonathan M Davis 
wrote:
> On Wednesday, April 24, 2024 11:53:18 PM MDT Richard (Rikki) 
> Andrew Cattermole via dip.ideas wrote:
>> Apart from literature review type content, there isn't much to 
>> discuss here. There is nothing to tune.
>>
>> I suggest you start work on a draft DIP and move to 
>> development unless Walter or Atila have strong opinions 
>> against it.
>
> Well, Walter has consistently shot down requests for this kind 
> of feature in the past (and there was a discussion in the 
> newsgroup within just the past couple of months where it came 
> up IIRC, and Walter shot it down then), so unless someone can 
> come up with a really compelling reason why it's needed, it's 
> going to be shot down. Unless something has changed quite 
> recently, Walter's opinion on this has already been made quite 
> clear, and it's been the same for years.
>
> The normal answer is that if you really need the other code in 
> the module to not have access to the class' members, then that 
> class should just go in another module. In practice, the 
> current situation rarely causes problems. It seems more to be 
> something that annoys some folks on principle rather than being 
> an actual technical issue. I would be shocked if this DIP went 
> anywhere.
>
> - Jonathan M Davis

The requirement in D, that there be no other code in a module 
(including unittests), other than a class, in order to 
demonstrate to the compiler (and those that read the code) that 
the class is meant to be truly encapsulated, is a consequence of 
the module being the unit of encapsulation.

Allowing a class to explicately define its encapsulated 
properties, seems to me, a much better solution, and consistent 
with what most people who use class-oriented oop would expect.

It would also solve consequences (1) and (2) outline in my 
opening remark.

(1) It makes it difficult to reason about a class definition in a 
module, when there is other code in the module, as all other code 
in the module is in essence a part of the class definition.

(2) It allows for accidental, unintended use of a private member 
by other code in the module, including unittests.

In the example below, neither the compiler nor someone reading 
the code, would know that the class is being used incorrectly in 
this unittest. Only by allowing the programmer of the class to be 
explicit about the encapsulated properties of the class, can the 
compiler and those reading this code below, identify the problem.

Yes, you could say the programmer must put the unittest in a 
separate module to the class, and then the unitttest can be 
interpreted correctly. But this extra burden on the programmer in 
completely unnessecary if D has something like private(this).

As for Walters opinion on this, I don't think I can recall ever 
seeing it, let alone any explanation for that opinion. But here 
and now seems like the best place to voice that, don't you think?

I've already given reasons for why this feature would be useful. 
The reasons are valid.

Objections to this idea should have there reasons as well, so we 
can test the validity of those objections.

btw. The problem in the code below, is one of 'principle'.


// --
module m;

class C
{
   private int _count; // visibilty of this member extends to the 
entire module.
   public void setCount(int c) { _count = c; }
}

unittest
{
   C c = new C();
   c._count = 42; // Actually, this is a mistake, and the 
programmer should be testing the public method setCount(..)
}

// ----