[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: API/Interface design questions

From: Ben Reser <ben_at_reser.org>
Date: 2004-03-11 19:25:47 CET

On Tue, Mar 09, 2004 at 03:52:57PM -0500, John Peacock wrote:
> Several of the functions which I have been working on to support the
> property keyword expansion have had altered signatures. Specifically,
> these two:
>
> svn_subst_keywords_differ()
> svn_subst_copy_and_translate()
>
> have had a pool term added. So for API compatibility, I need to create new
> functions and turn the above into wrappers, so I was hoping for some
> guidance on appropriate names for the new functions (appending "_pool"
> seems kind of lame).

I think we should use svn_*_ex() for such functions. I also think if
they take any flags (svn_boolean_t's) we should migrate them to a single
int field with constants to set it. This allows us to add flags without
changing the function signature. Which keeps our API much cleaner in
the long run. When we get to 2.0 we can force everyone to switch over
to these functions.

> What I'd suggest is that the existing/patched svn_subst_keywords_differ()
> becomes svn_subst__keywords_differ() and a shim with the original name
> wraps it (with the appropriate pool creation/destruction). Would this be
> appropriate? The wrapper function could then be marked for deprecation in
> 2.x.

Pardon my ignorance, but what exactly is the "use chain" of these
functions? I've thought about making an option for mod_dav_svn to
replace keywords for non subversion clients (e.g. browsers doing a GET).
I'd need a way to do the translation. So if making these private would
remove the library call to do that, I'm not in favor of that. If it
just forces me to use a higher level function, I'd be okay with that.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 11 19:26:02 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.