Re: group modules into subdirectories

[Paul Eggert]

Bruno Haible <address@hidden> writes:

Like others, I like the idea of grouping but I'm afraid the initial
group proposal didn't sound that felicitous.

> The expected benefit is that
>   1) that people looking for a particular function and whether gnulib
>      support it can find it immediately, without grepping the repository
>      or the MODULES.html file,

I don't see this as much of a benefit.  As gnulib grows, people will
inevitably use indexes and searches as their first and favorite way to
find stuff.  If I'm trying to find something in an unfamiliar area
(FreeBSD sources, for example), I am inevitably frustrated by trying
to look at the directory hierarchy; it's much better to use 'grep -r'
or Google.

The gnulib directory structure should provide loci for gnulib's
maintainers, not loci for people trying to find functionality.

>   2) by looking at the name of the module, you can tell faster what it
>      does. For example, the fcntl and time modules provide a header, not
>      a function - this is not clear for an outsider.

This doesn't strike me as being worth the cost.  The idea reminds me
of the Hungarian notation <http://en.wikipedia.org/wiki/Hungarian_notation>,
which was a mistake to begin with (eventually Microsoft figured this
out and dumped it).

>   3) when a gnulib developer searches for the idioms used for headers or
>      for functions, the "pure" idioms are easier to find.

This motivation makes sense.

> Is it worth leaving "symbolic links of modules" in place of the old module
> names, and have gnulib-tool warn about uses of the old module names,
> to make transition to the new module names smoother?

Probably not.

Without being too specific (sorry, I'm supposed to be working on other
things right now....), I propose that the subdirectories be made for
the convenience of gnulib developers, not for that of gnulib's users.
This is reminiscent of the idea behind Java's packages, which are
better used as maintainer boundaries, not functionality boundaries.