> Hi Lucas Hi, Phillip! > These all look like good changes. Looking through this series I do think that > it would be more readable and maintainable if you adopted the table drive > approach suggested by Junio. Today I had a meeting with my mentors (Karthik and Patrick), and yeah, this is something that I'll change in v4. Returning the keys in the same order as they were requested in the null-terminated format is not so useful now that I'm keeping the keys in the output. Dropping this assumption allows me to make this code simpler. > That way we would avoid the nested switch statements and each piece of > information only needs to be retrieved once rather that having to retrieve it > separately for the JSON and plaintext output. Below is a sketch of might look. > Each key is handled by a callback and we have a table that maps key names to > callbacks. For the json output we use one json writer per category to build > output for each category. At first glance it looks good to me. It still seems to me that it needs to somehow treat duplicated keys.
