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

[NotYouAgain]

On Saturday, 27 April 2024 at 11:16:08 UTC, Kagamin wrote:
> On Saturday, 27 April 2024 at 10:58:17 UTC, Arafel wrote:
>> On 27/4/24 12:22, Kagamin wrote:
>>> In OOP world you enforce contracts with interfaces, not with 
>>> access attributes. Do you really come from java?
>>
>> I don't understand you. Are you arguing that we don't need 
>> `private`, or even visibility, at all, because we should just 
>> use interfaces?
>
> If you prefer hardcore OOP, yes. Interfaces for contracts is 
> OOP best practice.


For me, type integrity is the most important thing.

Well, type integrity is important for any type really, not just a 
class type.

Imagine if you could put "hello" into an int, simply because the 
int was in a module with other code, and therefore lost the 
ability to protect its integrity.

private already exists, and provides the **necessary** support 
for enscapsulation of the class type from code *outside* the 
module.

This discussion is really just about a new access modifier => 
private(this),
to provide better support for encapsulation of the class type 
from code *within* the module.

There is no argument that the class should not have, or does need 
to have, the means to protect its type integrity. D has knows it 
needs this, but only allows it in relation to code outside the 
module.

I'm saying, I need it in the module, because the one-class per 
module is not my thing.

If there's disagreement, its because some don't think I need 
that, and that the one-class per module is all their willing to 
offer me. They believe a class-type should be a sub-type of a 
non-type (i.e. the module). That's where I firmly disagree. 
Ensuring that operations on a class type are compatible with its 
design, could be left to 'software engineering', sure, but a tool 
like private(this) provides a mechanism to express that intent 
'explicately', which makes the class-type a strong type again. At 
the moment, its a pretty weak type when other code is in the 
module with it.

"A strong type is the software engineering superstructure for 
programs".

That is where I begin my programming. With a strong type, not a 
weak one, that lacks any real border.

As such, whenever I code my class-type, I want the means to 
protect its type integrity, regardless of where the surrounding 
code exists. More importantly, I want the compiler to understand 
and enforce that integrity. If I didn't need that as well, I 
could use 'convention', and then ... hope for the best...

But even Javascript learnt, that convention is not enough..

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties

If there is any disagreement to the idea of private(this), it 
needs to be on the basis that a weak type is fine, and that I 
should just accept that.

'Pretending' its a strong type by ensuring no other code is the 
module with it, is a pretty poor solution for a programming 
language.

I need this tool so that I can explicately declare intended 
meaning in my type *and* have the compiler on my side enforcing 
that.

The proof of a type, is in the type of its proof.