John Peacock wrote:
> Julian Foad wrote:
>
>> One thing you could do if people don't like it is keep the existing
>> implementation of that function (which doesn't need a pool) rather
>> than changing it to a wrapper around the new function.
>
> I don't see how that is possible; as a deprecated function, I have to
> support it to the best of my ability using the new functionality, since
> there is no way to support it with the old (the data doesn't exist that
> way any longer).
Sorry - I didn't specify which function I was talking about. I was talking
about "svn_subst_keywords_differ" which doesn't call any other functions so
could just be kept as-is.
There is also "svn_subst_translate_stream" which does call other functions, and
it wouldn't be so straightforward to keep it. As you imply below, you'd also
have to keep some other functions on which it depends.
> Or are you suggesting that I keep _all_ of the old
> functions around for compatibility purposes, and have API/code
> duplication instead of compatility wrappers?
No, it's fine to keep just the minimum necessary to achieve compatibility.
> As a deprecated function, however, I expect fewer callers to it over
> time (actually as a function which probably should not have been part of
> the public interface, I don't expect _any_ callers to it). So the minor
> /faux pax/ of creating a top-level pool with a very brief lifespan
> should be a forgivable limitation.
Agreed, unless someone tells us that a top-level pool is worse than just a
minor /faux pas/.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 17 15:29:18 2005