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

[NotYouAgain]

On Friday, 26 April 2024 at 16:38:54 UTC, Steven Schveighoffer 
wrote:
> ..
> ...
> 1. unittests being able to examine/manipulate private data is 
> *expected* and *desired*. How else do you plan to validate 
> things are happening properly without having to expose more 
> public functions than necessary? I'd expect a line such as 
> `assert(c._count == 0);` to be a valid line in a unittest.
> 2. unittests generally are placed close to the things they 
> test, and in fact are required to do so for documented 
> unittests. This means they will be inside the class, and still 
> have access to `private(this)` data.
>
> I don't find the arguments compelling enough to make this new 
> feature. An entire module is as examinable as an entire class 
> definition. It's already open in your editor even.
>
> -Steve

I don't agree with any of those propositions.

What value is there in allowing 'c._count == 0;' to be a valid 
part of a unittest when the class design implicitely (cause there 
is no explicit attribute available) makes c a private member to 
only be accessed through a public method?

You say 'An entire module is as examinable as an entire class 
definition.' - I say, that is exactly the problem that 
'private(this)' can fix!

i.e. I want the class definition to be the class definition, and 
not the module definition to be the class definition.

At the moment, a class definition inside a module that contains 
other code in the same module, is about as useful as: int foo(T* 
p); "Is p an array? is foo() going to mutate what it points to? 
Is foo() going to free() it? How would I know without reading the 
implementation?" - Walter Bright.

It also makes the unittest in a module, an unreliable tool for 
testing - as you cannot rely upon the unittest to test what you 
think it should be testing.

Only in D, can a class definition mean something completely 
different when there is other code nearby. I'm not aware of any 
other language where the same applies.

It's worse than C++ friends. It's friendship galore... there is 
no way to control it inside a module, making classes difficult to 
reason about without taking into account all other code in the 
module. And using unittests in the same module as the class, as a 
tool for design verification tool, is just pointless - and prone 
to errors, as I've demonstrated - since the compiler cannot 
reason about the class intent either.

D is different to many well known languages, in that it stems 
from pragmatism more than theory. But ignoring type theory has 
consequences.

How can you reason about a class type, when that type has no 
means to control its own borders? Those borders are just as 
important 'inside' the module, as they are outside the module. 
This I think, is where any disagreement applies. All I'm asking 
for, is the tool to create those borders for use 'inside' the 
module.

You see it as a 'new' feature' I see it as a feature that should 
already be there.

There are clear benefits that arise from such a tool, as I've 
begun to demonstrate.

If you're saying these benefits are not real, I have to disagree.