Karthik Nayak <karthik....@gmail.com> writes: >> I do not see much point in renaming between these two. The latter >> makes it sound as if this is only for "filtering" and from that >> angle of view is probably a worse name. If you do not think of a >> better one, and if you are going to name the array that contains >> this thing "ref_list", calling "ref_list_item" would be following >> suit to what string-list did. >> > > Well I just wanted to keep it related to 'ref-filter', I think > 'ref_list_item' > sounds better after seeing your point of view.
Also I think Matthieu already commented that "filter" was out of place for that struct. I still think your ref_list is better called ref_array, but that is a minor point. Use of "foo_list" in our codebase is predominantly (because we use "commit_list" very often in the core part of the system) for a linear linked list where you do not have a random access to the items. string-list is misnomer, I would think. > I didn't know about the "we are trying to move away from calling the > name of objects as "sha1[]"". Will leave it as objectname then. I think you now know after seeing that 56-patch series ;-) >> You didn't explain why you reordered the fields, either. Were you >> planning to make the name[] field to flex-array to reduce need for >> one level of redirection or something? >> > > Yes! exactly why the re-order, was going to rebase it and squash it > in, if the code seemed to be up and running. If that is the case, I would suggest making that "turn it flex array" a separate step. -- 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
