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

[NotYouAgain]

On Saturday, 27 April 2024 at 07:39:19 UTC, Jonathan M Davis 
wrote:
>
> What I'm saying is that there isn't actually a problem that 
> needs solving. It's a theoretical issue and not one in reality.

That's nonsense. Almost every oop that looks at D, will discover 
the problem themselves.
The compiler won't help them.

You assume that oop will comes to D not expecting private to mean 
private to the type?

They will come to D expecting private to be private to the type.

They will discover the same issue that I've uncovered, and will 
need to adjust their thinking to that a class is no longer 
considered a type in oop in D, but a subtype of the module.

Again, Swift done it right. D done it wrong.

oo programmers coming to D will have to live with a programming 
langauge that does it wrong.

> Programmers routinely program in D without running into any 
> issues with private. Some of them even think that private is 
> private to the class or struct and are surprised years later to 
> find out that it isn't, because they never have problems with 
> it.

They haven't developed an extensive library using class-oriented 
oop style then ;-)

Most likely, they're using D for its C like capabilities.

> Visibility attributes are necessary for controlling the public 
> API, which D's private does just fine.

No. Visibility is related to the type as well. This is where D 
got it wrong.

Swift got it right.

> From what I've seen, the only problem that we actually get from 
> it is people being surprised that D's private is private to the 
> module and then who want it to work differently (or who want 
> something like private(this) in addition to private), because 
> they think that it's good OO programming to have that and that 
> it's dirty otherwise.

Why would they be surprised do you think?

Yes, it is good OOp programming to have private attributes.

And 'dirty'? wtf does that mean?

> But from a practical standpoint, I'm not sure that I've ever 
> seen a bug reported that happened because private was for the 
> module and not the type.

private(this) is not about fixing bugs. It's about fixing type 
design.
It's about fixing unittest so that they actually test the design 
of the type.

>
> In my experience, there simply isn't anything to worry about 
> here, and usually, the folks who are worried about it are 
> worried about it because it's not what they're used to or 
> because it doesn't fit in with their ideal view of OO 
> programming.

It's about an ideal language in which to do oop.

D claims to support oop. but then insist that they rethink what 
oop is.

No, I want to do what I know to work. D claims I can do that, but 
it doesn't live up to that claim.

> It is a topic that I've seen come up periodically over the 
> nearly twenty years that I've been using D, so it's far from 
> new, and it will probably never go away as long as things stay 
> the way that they are...

Enter 'private(this)' .. and you'll never ever have to here about 
it, ever again ;-)

> but it's almost always newcomers complaining...

And why do you think that is?

Would they be making the same complaint if they used Swift? Not 
likely.

Serious oo programmers will likely go elsehwere once they 
discover how D insists they conform to the way D want them to 
think.

> problems, but private being private to the module really hasn't 
> been causing problems in general.

And yet, so say its a topic that keeps coming up, and will 
continue to keep coming up.

If it's not causing a problem, perhaps its because to the people 
to whom it was causing a problem, have gone elsewhere... so it's 
no longer a problem for D.

> So, yes, I bring up moving code to other modules as a solution 
> if you actually want to guarantee that it doesn't have access 
> to the code in the module that it was in, because that will 
> give you that guarantee. But it's not something that I'm 
> arguing that folks should be doing as best practice, because it 
> simply isn't necessary in practice.

I want that guarantee. In fact, I insist that any language I use 
provides that guarantee.

I also insist that it doesn't require more effort than what it 
should.

adding (this) to private, is the less effort possible.

I don't want to see the bugs arise, I want to prevent them from 
arising, with the least effort possible, from me.

The module is not a type, and the class should not be a subtype 
of it. The class itself is the type. It should be able to assert 
control over itself, like other types.

> And because I have not seen anything that private(this) is 
> trying to solve as something that's actually causing problems, 
> I don't see any reason to add a language feature to try to 
> solve those problems.
>
> - Jonathan M Davis

You (and others) provide alternatives to private(this) when 
people discover those problems, but you (and others) don't see 
what the problem identified, as a problem, but as a non-problem, 
but still, one requiring a solution? I don't get the logic in 
that.

If there is no problem, why propose the one class per module, one 
unittest per module, solution?

Yes. I know the argument. C++, C#, Java, Swift, Javascipt, 
Haskell...etc. programmers are the actual problem, not D. They 
come to D expecting the wrong thing..It's their thinking that is 
the problem, not D.

That's not a convincing argument. Never has been. Never will be.

private(this) and the problem is no longer there. All those 
programmers will not be required to change how they think. D 
might even become popular then.