Derrick Stolee <stolee@xxxxxxxxx> writes: > On 7/8/2020 10:25 PM, Jonathan Tan wrote: >>> This list is also inserted into a hashmap. This allows command-line >>> arguments to quickly find the tasks by name, not sensitive to case. To >>> ensure this list and hashmap work well together, the list only contains >>> pointers to the struct information. This will allow a sort on the list >>> while preserving the hashmap data. >> >> I think having the hashmap is unnecessarily complicated in this case - >> with the small number of tasks, a list would be fine. But I don't feel >> strongly about this. > > You're probably right that iterating through a list with (hopefully) > at most a dozen entries is fast enough that a hashmap is overkill here. > > Now is the real test: can I change this patch in v2 without needing > to mess with any of the others? The intention here was to make adding > tasks as simple as possible, so we shall see. :D Adding a new element to a list would be simple no matter how the list is represented. But I think the real question is what access pattern we expect. Do we need to look up by name a single one or selected few? Do we need the iteration/enumeration be stable? etc.
