From: Karsten Blees Date: Thu, 26 Jun 2014 19:19:42 GMT Subject: Re: [PATCH v3 2/3] config: add hashtable for config parsing & retrieval Message-ID: <53AC724E.3090106@gmail.com> In-Reply-To: Am 26.06.2014 21:00, schrieb Junio C Hamano: > Matthieu Moy writes: > >> Junio C Hamano writes: >> >>> When the submodule script that uses "git config -f .gitmodules" is >>> converted into C, if the updated config API is ready, it may be able >>> to do something like these in a single program: >>> >>> const char *url; >>> struct config_set *gm_config; >>> >>> /* read from $GIT_DIR/config */ >>> url = git_config_get_string("remote.origin.url"); >>> >>> /* >>> * allow us to read from .gitmodules; the parameters are >>> * list of files that make up the configset, perhaps. >>> */ >>> gm_config = git_configset_new(".gitmodules", NULL); >>> >>> >>> if (!git_configset_get_bool(gm_config, "submodule.frotz.ignore")) { >>> /* do a lot of stuff for the submodule */ >>> ... >>> } >>> >>> /* when we are done with the configset */ >>> git_configset_clear(gm_config); >> >> Isn't that a bit overkill? Why not just let the caller manage a hashmap >> directly instead of a config_set? > > Because I had an experience under my belt of a painful refactoring > of "the_index" which turned out to be not just a single array, I > simply suspect that the final data structure to represent a "set of > config-like things" will not be just a single hashmap, hence I do > prefer to have one layer of abstraction "struct config_set", which > would contain a hashmap and possibly more. Doesn't "is the hashmap > initialized" bit belong there, for example? Would an additional int hashmap_is_initialized(constr struct hashmap *map) { return !!map->table; } API help? (Note that hashmap_free() already does memset(0), so the usual notion of "zero memory means unitialized" applies).