Karl Fogel <kfogel_at_red-bean.com> writes:
> Greg Hudson <ghudson_at_MIT.EDU> writes:
> > On Thu, 2008-08-28 at 10:48 -0500, Hyrum K. Wright wrote:
> >> Reimplementing everything in terms of the latest function introduces a subtle
> >> kind of code duplication that I'd rather avoid. And where there's code
> >> duplication, there's bugs.
> >
> > It might be good to look at some examples.
> >
> > My gut reaction is that if it's more concise to use the
> > next-most-deprecated API instead of the current API, we didn't
> > necessarily improve the API with our changes. But that's just theory.
>
> I tried to do this in the past with some big change, I can't remember
> which. I stopped when people objected, but my memory was that it was
> mostly drudge-work -- not challenging, just some extra work.
Reimplementing all deprecated functions each time we rev it again
is downright dangerous. We have NO TESTS of these rewritten
functions. This is true even if we rewrite each one only once,
leaving a chain of deprecated functions calling each other.
One such rewritten deprecated function almost shipped in 1.5 in a
completely non-working (segfault) state if I hadn't found it by
accident (r31055). I wrote a test for it using the Python
bindings, which is the easiest approach to unit testing.
Subversion is mostly tested only in the way that svn(1) calls the
APIs, and API use by anything else is strictly at own risk.
--
Eric Gillespie <*> epg_at_pretzelnet.org
---------------------------------------------------------------------
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-02 03:36:51 CEST