Re: [PATCH v3 2/3] config: add hashtable for config parsing & retrieval

From: Karsten Blees <karsten.blees@gmail.com>
Date: Jun 27, 2014, 08:19 UTC
Message-ID: <53AD2914.4030508@gmail.com>
In-Reply-To: <xmqqzjgz2wqr.fsf@gitster.dls.corp.google.com>

Am 26.06.2014 23:21, schrieb Junio C Hamano:

Show 23 quoted lines

> Karsten Blees <karsten.blees@gmail.com> writes:
> 
>>> 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.
>

That the variable is redundant was all I was trying to say, sorry for the misunderstanding. But reading through api-hashmap.txt again, I found that documentation of the hashmap members is pretty vague, so perhaps improving the docs would suffice (e.g. "hashmap.table != NULL indicates the hashmap has been initialized.").

Show 6 quoted lines

> 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...
>

I think having an extra type for the configuration is a Good Thing (even if the only member is a hashmap). Although I wouldn't call it 'config_set', as it conflicts with the verb 'set', resulting in weird APIs ('config_set_get_value()', 'config_set_set_value()'). Perhaps 'config_map' or 'config_settings', or just 'config'?