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
