Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > But if we do that let's do that with an API where we simply pass this > custom string in as another parameter to the function, rather than > having a state machine to parse it out of the array we use for the > "usage:" and "or:" list of lines. Sorry, but I do not follow. A perfectly fine way to encode the three (usage:, or:, and text) kind of information in a single array is what this step is breaking, and then you propose to keep the two still in that same array, with only the third kind kicked out to "another parameter", which does not make much sense to me.
