On Mon, 2004-11-15 at 11:18, John Peacock wrote:
> The laudable notion of providing a strong API compatibility guarantees needs to
> be matched with an equally strong, conscious decision of what exactly
> constitutes the Public API. Just making every function that is used by more
> than one set of libraries part of the Public API isn't design; it's accretion.
No, it's a design. It's a design you don't like, and it's not a perfect
design, but it's not "accretion."
> The function that I am having a problem with, svn_subst_copy_and_translate, is
> truly a low level function that requires specific setup before being called. It
> is a poor candidate for a public API, since to use it in third party code would
> require duplicating much of one of the already existing higher level functions.
I think if that were really true, we wouldn't be using it in three
places in libsvn_client.
> If I were to bring my patches up to date now, would I get grief from people that
> adding a third iteration of svn_subst_copy_and_translate would "muddy" the API.
There's no need for concern here; we've been quite willing to rev APIs,
and we've never shot anything down because we didn't want to rev an API.
In fact, I'm not sure that it makes sense to consider your
keywords-as-hash patch in the absence of a second properties-as-keywords
patch (which, as you've acceded to, doesn't itself make a whole lot of
sense in the absence of inherited keywords or at least a better
auto-props mechanism).
My reasoning is that making svn_subst_copy_and_translate() more flexible
doesn't add a lot of value, because the real constraints on substitution
come from svn_subst_build_keywords(). Turning the keyword structure
into a hash is a modest design improvement, but there's no need to
"future-proof" the code against a change we're not ready to make yet,
when the API is already "future-proof" via the API-revving mechanism.
The reason *not* to consider your keywords-as-hash change now is that we
have to rev svn_subst_build_keywords() once for keywords-as-hash and a
second time for properties-as-keywords. (This would be okay if
keywords-as-hash had some intrinsic value--as I've said, we're not
terribly resistant to revving APIs--but it doesn't make much sense
without that value.)
In fact, the keywords-as-hash change you submitted added properties as
an argument to svn_subst_build_keywords() in anticipation of the
properties-as-keywords change. I don't agree with doing that before
we're ready to have properties as keywords.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 15 18:58:09 2004