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

[Mike Parker]

On Saturday, 4 June 2022 at 11:15:13 UTC, forkit wrote:

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

As I see it, this is a matter of "thinking in D" vs "thinking in 
something else". When you think in the language you're using, you 
organize your code to best take advantage of that language's 
features. D gives you the tools you need to have the strict 
encapsulation you want--classes can go in their own module; 
package modules present a single module interface to the world; 
package protection allows internal access within the package 
where necessary. What I don't understand is, what's so hard about 
that?

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

Two things here.

1) There's a fundamental disagreement that encapsulation is 
broken. As I see it, it isn't broken. Any class I implement in a 
module is encapsulated from outside that module. I don't have any 
need for encapsulation inside the module, anymore than I would 
have any need for encapsulation inside the class (i.e., 
restricting access to a private member to a single member 
function). Since they're all in the same file, there's no 
difference whatsoever outside of a conceptual one. If you have 
access to the module's source, you have access to the private 
members.

2) A solution exists for anyone who cares about that conceptual 
difference. We don't need a new keyword/attribute to do something 
you can already do.


> 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 would almost say "Exactly!" to this, if not for the "all the 
encapsulation anyone will ever need". The module is the unit of 
encapsulation in D. But, as you demonstrate, some people just 
aren't comfortable with that. So they have the option to put 
their classes in separate modules.