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

Re: Is the runtime configuration seeping too deeply?

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-05-26 20:49:56 CEST

"C. Michael Pilato" <cmpilato@collab.net> writes:
> In retrospect, though, this makes for an awkward API. Why should callers
> need to generate a whole configuration structure just to pass a string value
> to these functions?
>
> I think I should change my code to do just that (and plan to do so). But
> here's my real question -- should we also change svn_wc_get_status_editor3()
> too, *removing* the 'config' parameter and adding the one 'default_ignores'
> parameter it actually needs? svn_wc_get_default_ignores(), which takes a
> 'config' hash, too, is the likely reason the status function takes a
> 'config' -- it just gets passed thru to svn_wc_get_default_ignores().
>
> I can't put my finger on the exact reason, but the runtime configuration
> area *feels* to me like something that only libsvn_client and individual
> client programs should even know about -- that the WC, RA, and server-side
> APIs should be ignorant of it, and take their instructions from their
> callers directly. (And yes, this means that svn_wc_get_ignores() and
> svn_wc_get_default_ignores() would need to be changed, too.)
>
> Thoughts?

+1

The config structure is a big grab-bag of stuff; we should be pulling
things out of that bag and routing them off to where they're needed,
not sending the whole bag every time and making the recipient know
where to look inside it.

Hmmm, maybe a better way to make that argument: the reason not to pass
the whole config is similar to the reason not to program with all
global variables,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 26 20:50:03 2007

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.