Re: [PATCH v3 2/3] config: add hashtable for config parsing & retrieval
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 26, 2014, 21:21 UTC
- Message-ID
- <xmqqzjgz2wqr.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <53AC724E.3090106@gmail.com>
Karsten Blees <karsten.blees@gmail.com> writes:
Show 17 quoted lines
>> 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).It may remove the need for the separate "hashmap_initialized" bit that was implemented as a file-scope global in the patch.
I however am not convinced that it will be the _only_ thing other than the hashmap we would need to use to keep track of the in-core "set of config-like things", and usually a blanket statement "these are the only thing we would ever need" tends not to hold for long, so...