On Sun, 5 Jan 2003, Greg Stein wrote:
> Drop the "private" part. They're already private based on where they're
> located, so there isn't a need to further qualify them. I'm also assuming
> that we can manage to avoid conflicts between the arch-specific and the
> public file names (since we manage both namespaces).
>
> IOW:
> +1 on using apr_*.h
> +0.2 on using apr_priv_*.h
> +0 on using apr_private_*.h
> -0 on using apr_*_private.h
My argument against using "apr_*.h" would be twofold.
First, at least for the unix include/arch/ files, all but one or two are
named exactly the same as their public counterpart, minus the apr_ prefix.
"apr_thread_cond.h" and "thread_cond.h", for example. As you say, we can
get around this, it just means coming up with some completely different
name than "thread_cond" for one of them just to get around the fact that
we don't want to stick "priv" or "private" in the name.
Second, when you're looking at something like:
#include "apr_file_io.h"
#include "thread_cond.h"
The fact that the former has an apr_ prefix and the latter doesn't helps
to distinguish that one is a portable header and one's an arch header. If
they all have the same namespace prefix, you have to do a little more
hunting to find your include files.
So, I'll say:
+1 on using apr_private_*.h
+0.2 on using apr_priv_*.h
-0 on using apr_*.h
-0 on using apr_*_private.h
and for shits and giggles, I'll even add:
+0 on using apr_arch_*.h
-0 on using apr_os_*.h [too confusing, since for example apr_os_file_t
would *not* be defined in apr_os_file_io.h]
--Cliff
