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.
Cheers,
-g
---------------------------------------------------------------------
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