apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject Re: arch specific include files, the naming thereof
Date Mon, 06 Jan 2003 04:59:50 GMT
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


Mime
View raw message