Hi Karl,
On 4/20/07, Karl Fogel <kfogel@red-bean.com> wrote:
> kfogel@tigris.org writes:
> > Log:
> > * subversion/libsvn_fs_fs/tree.c: Include private/svn_mergeinfo_private.h,
> > to avoid warning about svn_mergeinfo__to_string being undeclared.
>
> Why do some files in include/private/ end in "_private.h" and some
> just in ".h"? The README in there doesn't mention anything about it.
>
> If it's just random, let's pick something and be consistent. I guess
> a "_private" suffix is probably a good idea, since that way even if
> "private/" were listed in -I<includes>, we'd still avoid name
> conflicts. So that would imply these renames under private/:
>
> ra_svn_sasl.h ==> ra_svn_sasl_private.h
> svn_atomic.h ==> svn_atomic_private.h
> svn_compat.h ==> svn_compat_private.h
> svn_fs_merge_info.h ==> svn_fs_merge_info_private.h
> svn_fs_util.h ==> svn_fs_util_private.h
> svn_client_mergeinfo_private.h === svn_client_mergeinfo_private.h
> svn_mergeinfo_private.h === svn_mergeinfo_private.h
> svn_repos_private.h === svn_repos_private.h
> svn_wc_private.h === svn_wc_private.h
>
> But I'd also be happy with no suffix:
>
> ra_svn_sasl.h === ra_svn_sasl.h
> svn_atomic.h === svn_atomic.h
> svn_compat.h === svn_compat.h
> svn_fs_merge_info.h === svn_fs_merge_info.h
> svn_fs_util.h === svn_fs_util.h
> svn_client_mergeinfo_private.h ==> svn_client_mergeinfo.h
> svn_mergeinfo_private.h ==> svn_mergeinfo.h
> svn_repos_private.h ==> svn_repos.h
> svn_wc_private.h ==> svn_wc.h
>
> Being consistent is the main thing. The cost of inconsistency is that
> people will think that having or not having a "_private" suffix means
> something important, and waste time trying to figure out what it is.
>
> (And if there is something important about the suffix, README should
> document it.)
>
In another thread, Dan and I are discussing the possible need to generate swig
proxies for these files. If the conclusion is that they need to have proxies
generated, my guess is that it would be simpler to do if these files
had the suffix
(as you say to ensure uniqueness).
--
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 21 07:02:51 2007