Re: Private header files

[Karl Fogel <kf...@red-bean.com>]

Greg Stein <gs...@gmail.com> writes:
> 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.

Making an API public is a commitment to maintaining it, including doing
the deprecation dance whenever we change it.

Meanwhile, when it comes to consuming Subversion APIs, Subversion's own
libraries are a special case.  We know this from experience -- that's
exactly why we made the include/private/ headers in the first place.
There were things we wanted to use that it just seemed unlikely anyone
else would want.  (And if people do want it, then the answer is easy: we
just promote it out of private/ and maintain it like any other public
API from then on.)

I mean, this wasn't something that got developed just for kicks.  It
solved a real problem: that there was no level of accessibility between
library-internal and fully-public, even though we found we kept needing
that intermediate level of accessibility.

Now would be the time to come up with some concrete example, and I'm too
lazy (read: swamped) to do that :-).  But if I haven't convinced you,
maybe I can dig around and find one...

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Private header files

[Greg Stein <gs...@gmail.com>]

Sorry, hard to respond inline.

Yes, i've already assumed it is incumbent on me to suggest any change.  
The current arrangement makes sense, tho it makes me a but  
uncomfortable. It's on me, so don't waste ur time.

Cheers,
-g

On Sep 20, 2008, at 17:14, Karl Fogel <kf...@red-bean.com> wrote:

> Greg Stein <gs...@gmail.com> writes:
>> 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.
>
> Making an API public is a commitment to maintaining it, including  
> doing
> the deprecation dance whenever we change it.
>
> Meanwhile, when it comes to consuming Subversion APIs, Subversion's  
> own
> libraries are a special case.  We know this from experience -- that's
> exactly why we made the include/private/ headers in the first place.
> There were things we wanted to use that it just seemed unlikely anyone
> else would want.  (And if people do want it, then the answer is  
> easy: we
> just promote it out of private/ and maintain it like any other public
> API from then on.)
>
> I mean, this wasn't something that got developed just for kicks.  It
> solved a real problem: that there was no level of accessibility  
> between
> library-internal and fully-public, even though we found we kept  
> needing
> that intermediate level of accessibility.
>
> Now would be the time to come up with some concrete example, and I'm  
> too
> lazy (read: swamped) to do that :-).  But if I haven't convinced you,
> maybe I can dig around and find one...
>
> -Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org