Matthieu Moy <matthieu....@grenoble-inp.fr> writes:
>>> 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.
> OK, I guess I overinterpreted what you meant by "struct config_set". If
> it's a thin abstraction layer on top of the hashmap (i.e. essentially
> contain the hashmap, and possibly a few more metadata), then it
> definitely makes sense.
Yup, and I do not strongly mind the initialization sequence of "if
you want to overlay from a file, call *_from_file()" you outlined;
an initialiser that takes a list of file paths to read from was
merely an example and not meant to be the sole interface (it is
overly rigid to be one).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html