private keyword dont appear to do anything

[Jonathan M Davis]

On Friday, November 03, 2017 14:52:22 H. S. Teoh via Digitalmars-d-learn 
wrote:
> On Fri, Nov 03, 2017 at 05:43:55PM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> > On 11/3/17 5:08 PM, Nathan S. wrote:
> > > On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote:
> > > > Most folks are surprised by this behavior
> > >
> > > I found it surprising at first but now any other way seems absurd to
> > > me.  None of the benefits of data encapsulation apply to code
> > > written five lines away in the same file.
> >
> > I also enjoy the mechanism, but I have to call this out as incorrect.
> > Encapsulation is about being able to prove to yourself exactly how an
> > object's private data can possibly be manipulated. It's not just 5
> > lines away, it's the whole file you have to review.
> >
> > If you have large flat files like Phobos, then encapsulation is
> > essentially impossible to review.
>
> [...]
>
> Arguably, many of these large flat files ought to be split up into
> smaller files.  For example, std.algorithm.* and std.range.* all tend to
> be conglomerations of basically-independent groups of structs and
> functions.  Iota and Cycle never interact with each other, and neither
> of them interacts with Recurrence, yet these all sit in the same file.
>
> Seems to me like a typical case of low cohesion, which, according to the
> ideals of encapsulation, ought to be grounds for splitting up the file
> into self-contained parts.
>
> But of course, there are pragmatic reasons for the way things currently
> are.

If you take that to the extreme, you just end up with a function per module,
which is pretty ridiculous IMHO (though that may be what you mean by
pragmatic reasons). And really, free functions like that are exactly the
sort of places where encapsulation tends not to matter much, because there's
nothing to encapsulate beyond the guts of the functions themselves, which
are already encapsulated. The situation is very different from something
like std.container where you have types which have member variables which
could be protected from access by other stuff in their modules if private
worked differently.

Figuring out a good way to organize a bunch of free functions is difficult
(as evidenced by the fact that plenty of folks have a hard time remembering
what is where inside of std.algorithm and std.range), but that's really not
an encapsulation problem, just a code organization problem.

- Jonathan M Davis