[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Private header files [was Re: svn commit: r33207 - branches/file-externals/subversion/libsvn_client]

From: Greg Stein <gstein_at_gmail.com>
Date: Sat, 20 Sep 2008 12:42:57 -0400

Hmm. I saw it more as private subsystems, or sharing data between
client and server bits.

The readme is kinda hard to argue with... Hmm. I'll take a look. It
just seems that if a library needs functionality from another, then we
should tweak the public api cuz somebody else may need it.


On Sep 20, 2008, at 11:18, Blair Zajac <blair_at_orcaware.com> wrote:

> Greg Stein wrote:
>> On Fri, Sep 19, 2008 at 11:09 PM, Blair Zajac <blair_at_orcaware.com>
>> wrote:
>>> Greg Stein wrote:
>>> Presumably being in include/private means it can be used across
>>> lib's.
>> This isn't right... Our libraries should not have privileged access
>> to
>> certain APIs that other users cannot reach. IOW, all 38 lines must
>> change :-P
> That's the purpose of all the headers in private:
> $ cat subversion/include/private/README
> Header files in this private/ directory are for internal APIs shared
> across Subversion's implementation. They are not part of the public
> API, nor are they ever copied into or under the include/ directory
> (e.g. by the installation process).
> You're effectively suggesting removing the entire include/private
> directory and promoting all the functions to public. Why would we
> want to do that? There may be APIs that we only want to support
> internally and not have the maintain in a public API.
> The only case I see for changing this is if we were to allow our
> libraries to be versioned independently so if you chance a private
> API without versioning it you can break the ABI, but we don't do
> that, so if we change a private API, it'll still be internally
> consistent across all the libs.
> I don't feel that strongly about it, as long as I can use the
> functions I need to make my coding easier :)
> Blair

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-20 18:43:39 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.