I've taken a quick look at this and, of course, it appears to mostly be
grunt code converting which I'm willing to do. However, I have an
inkling that there could be some stylistic nits that I would rather get
out of the way before I do much work on it.
Two possible ways to handle the changes to caller code are to:
1. Change it to build a struct and pass it in place. Probably
simplest, but would take the most coding to convert and, IMO, is
something of a pain to code up new notify callers (gotta build a struct,
init all fields, etc). Also has low overhead. A drawback (IMO) is that
new fields added to the notify struct may not get set properly in all
places if careful attention is not paid to all callers when they are
added -- of course, old caller code may not care to set new fields
anyway (beyond a zero value).
For example, instead of:
if (baton->notify_func)
(*baton->notify_func) (...)
It would be something like:
if (baton->notify_func)
{
struct svn_wc_notify_struct_t n; // or put this in a pool?
memset(&n, 0, sizeof(n));
n.baton = notify_baton;
n.path = path;
...
(*baton->notify_func) (&n);
}
2. Use a wrapper macro or function to build the struct and call the
callback. Less typing for me to convert the current caller code, and
IMO, easier for new callers to use, and when new fields are added the
old caller code will get an error or warning about not having all the
parameters. A macro would introduce less overhead than a wrapper function.
Something like:
SVN_WC_NOTIFY(baton->notify_func, notify_baton, path, ...)
3. Leave well enough alone. Very easy to do. Only real drawback is
some pain for clients when new fields are passed in the callbacks.
4. ??
Anyone care to comment?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 13 03:36:11 2003