Using closure in function scope to make "real" private class members

[forkit]

On Wednesday, 8 June 2022 at 03:52:05 UTC, Ola Fosheim Grøstad 
wrote:
>
> That is a weird take. The word can mean private to the file or 
> module, whatever the language defines as the basic unit. 
> Nothing wrong with that, just unusual in language design to use 
> that word inside a class with that meaning.
>

What the language does, is what the language does. I accept that 
different languages take different decisions around these ideas.

But an ability to put up a barrier around some aspect of a class, 
using 'private' for example, is clearly a benefit. Where is the 
downside? I don't get it. If you can put up a barrier, you should 
also be able to take it down of course (hence 'friend').

It's what C++/Java/C# programmers can already do. Why would a 
language want to intentionally, take that away, and even go so 
far as bragging about it?

Even worse, refuse to even consider an option to put if back?

I just don't get it. It makes no sense to me, whatsoever. It's 
truly beyond what I'd expect for a language that wants to compete 
with the likes of C++/Java/C#.

I like D's module system cause its convenient and easy to use, 
and it lets you group logically related abstractions together, in 
one place. Yey! I really like this. I can even get used to 
everything being a friend. It doesn't take much cognitive effort 
to do that ;-)

But not even having the option to put up a barrier around my 
abstraction to ensure some parts are hidden from surrounding code 
in the module, is too much.

A module containing a large number of related, but potentially 
leaky abstractions, doesn't sound that great to me ;-)

As you mentioned in a previous post - no I have to go build a 
static analyser, cause the compiler is completely useless here.

D has really taken something away. Something I've always had. 
Something I need, and something I rely upon. Something I want.

>> C++ friend is not something you should be using all the time. 
>> It breaks encapsulation. It does not enhance it,
>
> Actually, it often does in my code. I use it to prevent 
> creation of the class outside the factory.

Nonsense. When you break the barrier, you've broken the 
encapsulation. Full stop. No if and buts about it ;-)

I accept that by breaking the barrier, you might have made your 
job easier. That's fine also.

I'd like to make my job easier too, by being able to put that 
barrier back up.