private keyword dont appear to do anything

[H. S. Teoh]

On Fri, Nov 03, 2017 at 04:30:21PM -0600, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Friday, November 03, 2017 14:52:22 H. S. Teoh via Digitalmars-d-learn 
> wrote:
[...]
> > 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).

It's not that ridiculous if you consider that some of the more
heavily-used Phobos functions are actually not individual functions, but
overload sets.  I know we have been trying to merge some of the
unnecessary overload sets for other reasons, but some of these overload
sets can get pretty big.  Compound that with the long string of
unittests associated with each overload, that has accumulated from a
long string of bug fixes, etc., and you have pretty good justification
for keeping just that single overload set in its own file, together with
its associated unittests, and potentially also other paraphrenalia like
enums or other declarations used by the overload set, but not used
anywhere else.


> 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.

Arguably, once a function grows past a certain length, it's time to
break it down into more manageable pieces.  Having a function sit in its
own file gives you a nice working space for this sort of refactoring,
without worrying about namespace conflicts with unrelated code.

Still, I agree that some degree of judgment is involved here.  If we're
talking about a simple function that will never grow past 5-10 lines, it
does seem a little pointless to keep it in its own file, just to adhere
to some ideal of encapsulation.

But IME, with Phobos code even simple functions eventually grow into
multi-page monsters over time, once you start adding type-specific
specializations to deal with performance issues and the like.  Just look
at std.algorithm.searching.find, for example.  Several different
overloads, and static if blocks within an overload, sometimes on the
lengthy side depending on the specific optimization being implemented.
Arguably we should factor out some of the static if blocks or overloads
into separate private functions for easier future maintenance /
management if more specializations are added, or we need to balance
between different optimizations based on different factors. Static-if /
else blocks just aren't very conducive to this sort of thing.  And being
able to do this in a file dedicated to .find would be cleaner than
having to do surgery in a 4600-line file (and having to deal with
potential merge conflicts with other unrelated changes to the same file
-- though git is so good at this that one generally doesn't run into
much of a problem).


> 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.

Well, std.container *has* been split into submodules per container type.
I think that's a much better organization than in std.algorithm.*.


> 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.
[...]

<half-serious> Perhaps the solution is to go the
one-overload-set-per-file route, with std/algorithm/package.d basically
importing everything underneath. :-P </half-serious>

(Shhh, don't tell Andrei, or we'll get another lecture about wasting
time on worthless things while more important things are left to do.)


T

-- 
All problems are easy in retrospect.