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

[NotYouAgain]

On Saturday, 27 April 2024 at 15:47:50 UTC, Arafel wrote:
> On 27/4/24 15:10, Dukc wrote:
>> I need to stress though, that you need to approach this 
>> subject with utmost diplomacy and humblety. Class-level 
>> |private| has been the very subject of more than one flame war 
>> in these forums. You will quickly become shunned if you're 
>> seen as instigating another one. The disclaimers you included 
>> at beginning of your post hint that you're already aware of 
>> that.
>
> I have to say I have been surprised at how strongly some people 
> react. I started by saying that I think it's a minor issue, has 
> a workaround, and the workaround doesn't even feel too unusual 
> to me. In short: I don't think it's worth raising a fuss, it's 
> just one of those odd quirks that you learn to live with.
>
> Still, I think it makes sense as a feature, and, honestly, I 
> see it as a low-hanging fruit: it's an addition to the 
> language, fully opt-in, it doesn't interact with pretty much 
> anything else*, and has an already working implementation with 
> even some real-life exposure to find out the rough edges.
>
> So given that there are few drawbacks (I would dare say none 
> beyond a very much hypothetical "complexity" in the language), 
> and acknowledged, even if minor, benefits, the question for me 
> becomes: "why not?".
>
> "Because that's how things are" is something I can happily 
> accept, as I have been doing so far, but not agree with.
>
> *: Assuming you define it as: "for `private(this)` members or 
> methods, code outside the class (or eventually struct) behaves 
> as if it were in a different module".

You are not the first to be 'surprised' by the reaction to such a 
simple, and sound idea.

Apart from the usual flamewares instigated by people in D who 
hate oop, think oo programmers are oop..philes, etc...etc.... the 
only real objection that I can fathom, is that in D, the module 
is the unit of encapsulation, not the class, and therefore if i 
use D, i need to think like that, and if I don't want to, then to 
bad for me.

I think that is the objection to which a debate is warranted.

Ignore all the other crap that always accompany's this idea. It 
has always been there, and will always be there.

The question is, does private(this) fundamentally change anything 
about D, or is it a minor change that would allow something that 
anyone who has ever written a class, be able to do in D. Or, do 
we accept that the class type must takes second place to the 
module (a non-type).

Swift is a great example of how both options (private and 
fileprivate) work together to solve programmers problems. They 
don't work against each other. The programmer can choose the 
option 'they think' is best for them. Swift does not try to 
coerce the programmer into thinking differently, unlike D.

Again, the idea is sound. It exists in practically all of the 
most widely used oo capable languages - even in OpenD. The change 
is simple. But the opposition is really fierce.

So anyone wanting or supporting this feature must be prepared to 
deal with that fierce opposition.  Most are not prepared to do 
that, hence the idea never progresses....

I am very comfortable challenging the statusquo ;-)

Some are (understandably), not.

Fortunately, we now have a forum group where the idea itself can 
be discussed. But even that is already proving to be difficult. 
Remember, the opposition to this is very fierce. So it really 
should not come as much of surprise ;-)

The D module is the unit of encapsulation, but it is NOT a type.

A class IS a type, and should have the necessary 'explicit' means 
to encapsulation those properties it wants to encapsulate. That 
is my argument. It really could not be simpler. It is certainly 
not an argument designed to provoke flame wars, as other would 
have you believe.

The most fundamental argument against it, is no, in D, a class 
doesn't need that option. .. because D already provides a means 
of encapsulation, the module, and that is sufficient... but if 
you really want a class that can have its own encapsulation 
properties, then put it in a module by itself.

So that last paragraph is the only opposition to it that is 
worthy of your attention.

Ignore all the other stuff ;-)