Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> writes:
> Hmm, maybe. The "... take advantage of the new code" refers to the
> possibility (or otherwise) of re-using your work to update these
> "older API" functions to the new API style. (also, see Junio's response).
I agree that, while caching the usual config files is the most
important, allowing other users of the config code to use non-callback
functions would be nice too.
Not really for efficiency, but because I find it far more natural to ask
"what's the value of config key XYZ" to the code than to ask "can you
parse all config keys in the file, let me know, and I'll tell you later
which ones I'm interested in".
> [In order to do this, I would have expected to see one hash table
> for each file/blob, so the singleton object took me by surprise.]
The singleton could be fine as long as it is optional. We can have
an API looking like:
int git_config_get_string(const char *key, const char **value) {
return git_config_get_string_from(the singleton config cache,
key, value);
}
int git_config_get_string_from(struct hashmap *map, const char *key, const char **value);
(or take a structure representing "a set of config files" instead of
directly the hashmap)
Now, the good news is that such API can be written later, without
breaking the API. So I'd say it's fine to keep the code as-is for now,
and make it more general later. No strong opinion, though.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html