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

Re: [RFC] Mark deprecated functions with SVN_DEPRECATED / __attribute__((deprecated))

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 19 Aug 2008 13:34:47 +0100

On Tue, 2008-08-19 at 05:25 -0700, Greg Stein wrote:
> 2008/8/19 Julian Foad <julianfoad_at_btopenworld.com>:
> > On Tue, 2008-08-19 at 13:14 +0200, Arfrever Frehtes Taifersar Arahesis
> >...
> >> > And yes, we can keep docstrings in the deprecated header so that
> >> > people can figure out how to upgrade their calls.
> >>
> >> Please don't move declarations of all deprecated functions to one header.
> >> IMHO it would only create a disorder.
> >
> > Yes, +1. I hope greg meant to create a set of deprecated headers, one
> > corresponding to each normal header. Something like:
>
> There is NO way that I would suggest *doubling* the number of headers
> that we ship. That is a total disaster. When I saw that hwright added
> another header for the checksum stuff, I kinda barfed a little. More
> and more headers will just add to the cognitive load to try and figure
> out how to write against our APIs. "Where do I find X?" "In one of
> those billion headers." Headers not directly associated with a library
> are painful (in this case, the functions appear in libsvn_subr).
>
> I really did intend to move all of these into one svn_deprecated.h header.

See below.

> The basic problem is that I'm going through svn_wc.h and it is a mess.
> Half of the header is deprecated crap. I don't want to see that.

Absolutely agree with that.

> What
> is the problem with one header?

The problem with one header is it will (in the limit) refer to every
type defined in all Subversion libraries: a big monolithic lump that
makes everything that includes it depend on every other type-defining
header in the system. To (optionally) include it in every header in the
system would be "a total disaster" - a circular-dependency nightmare and
corresponding slow compilation speed.

Have I missed something that would make this a non-issue?

> These are deprecated functions. There
> is no need to consider or refer to them. Only if a developer wants to
> upgrade the call do they need to sort it out, and there will be one
> extra header to look at to find a docstring to figure out how to
> upgrade. And so what if *that* header is huge? It will be organized by
> original header, so it isn't going to be super scary -- just big.

I accept and agree that from an information-finding point of view it is
no real problem to have them all in one header, if there is an elegant
solution to the problem above.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-19 14:35:07 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.