On 09/18/2012 07:21 PM, Junio C Hamano wrote: > Michael Haggerty <mhag...@alum.mit.edu> writes: > >> If another sort order is needed, then we will either have to audit >> existing string_list users to make sure that they don't rely on strcmp() >> ordering, or we will have to implement strcmp() ordering *plus* the new >> ordering. > > What I was envisioning was to pass in an optional custom comparison > when you instantiate a string_list object. Existing callers that > rely on (or can live with, because they do not care about the exact > order) the default order will continue to use the byte-value ordering, > so there is no need for auditing. Only the new callers that want > different ordering would set custom comparison routine. > > But now I wrote it down, I realize that there is no _harm_ in > documenting "we sort in byte-value order, so expect iterations on > sorted string list to give them in that order to you" at all. > > So let's go with your documentation patch as-is. > >> It's not that I'm unwilling to implement 2; it's just that I still don't >> see any advantage to doing so before there is a demonstrated need for it. > > As I said, I have this suspicion that the lack of demonstrated need > is largely because the existing code that do _not_ use string-list > don't do so because the interface is limited, so the argument is > sort of self-fulfilling.
I've been looking for places in the code where string_list can be used, so hopefully I'll get a feeling for what new functionality will increase its applicability. Now that my string_list enhancements are in master, I will start trickling in patches to convert other code to using string_list when it seems to benefit code length and/or understandability. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
