David Glasser wrote:
> A much simpler way to accomplish the same goal is to stop the bizarre
> new trend of, every time svn_api_foo2 is implemented, instantly
> "upgrading" every call to svn_api_foo to use svn_api_foo2 instead.
Is it a new trend? I thought we'd been doing that for as long as we've
been revving APIs.
> Leaving the old calls in (except for cases where the caller really
> does need to use the new functionality) means that our own codebase
> will automatically test the backwards-compatibility code. Plus, this
> would mean doing less work and reduce pointless code churn that makes
> merges more difficult.
There is something in what you say. However, your tone is as if what
we're doing is obviously and tragically wrong. Did you consider that
there might be good reasons for what we do?
To claim it would automatically test the back-compat code is too
optimistic. Depending on the kind of revision, in some cases we want to
update all callers anyway (e.g. changing "recurse" to "depth") and in
such cases we would never get that advantage. In other cases we may only
want to support a feature that one caller wants; in such cases, note
that by NOT updating all the others we would fail to test the NEW
version so thoroughly, and testing the new API is often a greater
concern, rightly or wrongly. (In those cases, I'm not talking about
testing the new functionality, just that the old functionality still
works through the new API, and that the new API is clean enough to be
reasonably usable in all the old call sites.)
Doing less work: yes.
Pointless code churn making merges more difficult: depends on these
arguments about whether it's done for a good reason.
Another argument for updating all calls is consistency: it is easier for
a human to understand the source code if the number of variations is
limited. And if we make sure to go through all the call sites and
upgrade them, that gives us a considerably higher chance of spotting all
the cases where we should be using the new capabilities.
Having said that, there is certainly room for us to reconsider the way
in which we revise APIs and their callers. For one idea, perhaps the
implementer should be asked to make one commit that adds the new API and
re-implements the old, without updating ANY calls, and let that run
through the build-bots before committing any updates to the callers. I
know that would only be a one-off check but it could be very useful.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369424
Received on 2009-07-09 17:26:39 CEST