On Thursday, 12 May 2022 at 16:04:09 UTC, Ali Çehreli wrote:
My view on private has changed over the years. I need to be
convinced that there is usage that needs to be protected. :) I
don't see people using types freely especially the ones that
are in the same module. The only argument for private is to
allow changing the implementation of published libraries in the
future.
I use private as part of my rapid dev process. You write code,
you get things working with no real worry for correctness or
careful interfaces. You cannot make an interface until you
actually know what you're making.
So you make things, with "bad" connections. Then you remove those
connections.
1. Get system working with lots of direct access to class
variables.
2. Make those variables forbidden (through private in C++).
3. The compiler now shows you every instance of your new
interface encapsulation violations. No human decision to opt-in.
No remembering to search. You have an automatically generated
list of violations to fix.
I do the same thing with a module called "g" (for globals). I
write new code into g, get it working. I can see how "dirty" a
file is by simply searching for how many references to the module
g there are. Then if I move the code into a proper new module,
all references to g magically fail. It is impossible for me to
leave dangling old code touching naughty internals, and I get a
nice error view of all areas that need attention. If the uses are
all over the place and not in only a few areas (instead of just
in logic() and draw(), but all over the place) then I know I need
to rewrite and introduce a system so everything is mostly in one
place.
In D, I can do the module based method, but nothing short of
renaming variables gives me a list of violations and, that also
makes all the correct internal accesses wrong. Because private
doesn't work.
Call it whatever keyword you want, I really want a 'private'
specifier for classes. It's incredibly useful.
