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

[NotYouAgain]

On Sunday, 28 April 2024 at 00:07:22 UTC, NotYouAgain wrote:
> On Saturday, 27 April 2024 at 22:59:29 UTC, Steven 
> Schveighoffer wrote:
>> On Friday, 26 April 2024 at 23:42:48 UTC, NotYouAgain wrote:
>>
>>> I don't agree with any of those propositions.
>>
>> OK, and that is understandable. What I'm trying to convey is 
>> that *this is a design decision*. You may not agree with it, 
>> but it is not something that I think is "fundamental" to OO 
>> programming.
>>
>> I don't need to continue this, I've said my piece, and I'm not 
>> interested in further discussion on this. If you end up with a 
>> more formal proposal I likely will argue against it, but no 
>> hard feelings, I fully understand that there are certain 
>> points of view that I don't agree with but that reasonable 
>> people will think is correct or better.
>>
>> We can agree to disagree, and still be friends ;)
>>
>> -Steve
>
> Actually, here is the fundamental problem:
>
> D won't let me expression my intent in the code below. Had I 
> wanted to express a const or an immutable (for example) I can 
> express it - D won't stand in my way there. But if I want to 
> something that the vast majority of class-oriented oop 
> programmers would expect to, that is, declare a member in my 
> class-type to 'actually' be private to that type, then D and 
> all the usual naysayers that come out when this topic is 
> raised, insist on standing in my way. No they say. You actually 
> don't need to do that. But if you do, put the subclass in 
> separate module. Put the unittest in their separate module as 
> well.
>
> So do you see the 'actual' problem here, or just the one you 
> want to see?
>
> That there is so much fierce opposition to such a simple 
> proposition, has always been bewildering. The source of that 
> opposition, is usually a hate for oop in general, a hate for oo 
> programmers (e.g calling them oop..philes), a wish to see oop 
> stripped complelely out of D, or an insistence that all 
> class-oriented oo programmers change how they think, so that 
> think the way D wants to them think (a form of mind coercion 
> really).
>
> The idea is that a class should have an option to have truly 
> private member, is sound.
>
> The oppostition is the fundamental problem.

class ClassWithPrivateField
{
   private int privateField; // actually, my intent here is 
private(this),
                             // but it cannot be expressed in D.
                             // guess I better put the subclass in 
its own module
                             // in the hope that someone thinks by 
doing that,
                             // I've expressed that intent.

   this() { this.privateField = 42;  }
}

class Subclass : ClassWithPrivateField
{
   private int subPrivateField;

   this()
   {
     this.subPrivateField = 23;
     this.privateField = 52; // is this a mistake? The compiler 
has no way to know.
   }
}