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

[Ali Çehreli]

On 6/4/22 04:15, forkit wrote:
 > On Saturday, 4 June 2022 at 07:04:35 UTC, Ali Çehreli wrote:
 >>
 >> ...
 >> I think the reason is there is no strong argument for one way or the
 >> other. There are two options:
 >>
 >> a) 'private' means "private to the class", which necessitates the
 >> equivalent of the keyword 'friend'. This option is what C++ chose.
 >>
 >> b) 'private' means "private to the module", which frees 'friend' as a
 >> user symbol. This option is what D chose.
 >>
 >> > I really do think there is idealogical resistance to such a
 >> change, and
 >> > it's this that brings about these strong reactions.
 >>
 >> Since D came after C++, it is clear that option b was seen to be
 >> superior. Let's hear arguments why option a is better than b.
 >
 > It's interesting that whenever this topic is brought up, that people in
 > the D community (like you, for example), try to rephrase it as if we're
 > all being forced to make a choice between A *or* B.
 >
 > I'd like to have A *and* B.

Languages don't provide every want without weighing pros of cons. It may 
very well be good to have both A and B but I am not convinced.

 > You normally come up with ideas to issues that people raise (even ideas
 > that to me see pretty ordinary)

I am happy to be simple and happily finding ways to become more so.

 > , except, when it is this issue??

I am not going to come up with ideas for non-issues. I asked whether 
you've seen a single case where somebody forgot to mark a variable 
'private' and there was an issue. I seriously doubt it. People are not 
crazy creatures that change members willy nilly.

In fact, encapsulation can be achieved purely by convention: Name all 
members in a special way e.g. with a leading underscore and let it mean 
"this is private" and you have encapsulation. Nobody will access those 
members. If they ever do access, that's because they have a business 
case to do so. I gave the real-world example of how one company did 
access D runtime's GC statistics, which happened to be marked as 
'private' when it was first designed.

 > Why this idea encounters sooo.. much resistance, is..well. interesting.

I man not resisting this idea but your presentation of it. You present 
it as if D is broken. I asked for your arguments for favoring per-class 
encapsulation vs. per-module encapsulation. I haven't seen those 
arguments yet but I suspect you favor class because other languages do so.

My "text book" reference was related: Is there a computer science 
consensus on class should be the unit of encapsulation?

I gave another example where your favoring per-class encapsulation comes 
short: What about private members that are accessed only by a subset of 
the member functions of a class. That pattern emerges a lot in my types. 
Does not the same logic apply to that case? Member function foo() can 
access array _buffer even though _buffer should be accessed only by 
bar() and zar().

I know one can put _buffer, bar(), and zar() in a different class and 
get lower level encapsulation but that's not different from moving code 
to another module to get lower level of encapsulation.

 > The rest of your response I couldn't make any sense of.. so I'll 
ignore it.

I tried to explain above:

- Why do you favor 'class' over module?

- If you stop at 'class', you will come up short.

 > In the end though, encapsulation of a class, in D, is broken

That is wrong.

And exactly that kind of mistaken but so-sure statement moves me to so 
much resistence. The encapsulation point is merely arbitrary. Please you 
explain why you are so strong on where you stop encapsulation. Why 
class? Is there a computer science theory behind it?

 > and cannot
 > be statically verified by the compiler

As I said, since nobody will reach private members willy nilly, static 
verification of it is overkill. Encapsulation can be achieved by a 
convention.

I will go further and note that private does not add any value to the 
program: Replace all with 'public' and the program will run in exactly 
the same way with exactly the same level of safety.

 > Since there is no option B, to do otherwise, is what I would consider
 > unsound programming, as it is not possible to reason about the code of
 > the class contained within a module, without understanding ALL the code
 > in that module.

Really? That does not make sense at all. Why would e.g. Vector's code 
have anything to do with List's code? How does one get a hold of an 
object of the other to access its private members? This kind of 
statement is misguided. I am afraid people new to programming will take 
those and be concerned. There is no such problem at all. I haven't seen 
a single case of such violation of encapsulation. None.

 > It's also not possible to prove (again, without human intervention) that
 > other code in the module does not violate the modular requirements of
 > the class.

My example above holds: List's code does not even receive a Vector object.

I don't know what kind of projects you work with but I am happy to never 
have encountered such violations of modular requirements. (?)

 > A possible counter agrument to the above, is that there is no
 > encapsulation of a class in D. The module provides all the encapsulation
 > anyone will ever need.
 >
 > I'm not sure I'd want to be on that side of the argument ;-)

You clearly are not and I proudly am.

Besides, there are other ways of providing encapsulation when really 
needed. The reason I don't hear the pimpl idiom in D circles is because 
nobody really needs it.

Ali