[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: Greg Stein <gstein_at_gmail.com>
Date: Tue, 19 Aug 2008 05:25:33 -0700

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.

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. What
is the problem with one header? 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.


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:25:52 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.