Hi Junio, On Mon, 8 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schinde...@gmx.de> writes: > > > I wonder, however, if we could somhow turn things around by > > introducing something like > > > > split_and_do_for_each(item_p, length, string, delimiter) > > ... <do something with item_p and length> ... > > > > that both string_list_split() *and* add_strategies() could use? We > > would then be able to avoid allocating the list and duplicating the > > items in the latter case. > > I do think such a feature may be useful if we often work on pieces of a > string delimited by a delimiter, but if the caller does not see the > split result, then the function with "split" is probably misnamed. > > I however suspect the variant of this where "delimiter" can just be a > single byte would not be so useful. > > If the input comes from the end user, we certainly would want to allow > "word1 word2\tword3 " as input (i.e. squishing repeated delimiters into > one without introducing an "empty" element, allowing more than one > delimiter characters like SP and HT, and ignoring leading or trailing > runs of delimiter characters). > > If the input is generated internally, perhaps we should rethink the > interface between the function that wants to do the for-each-word and > its caller; if the caller wants to pass multiple things to the callee, > it should be able to do so without first having to stuff these multiple > things into a single string, only to force the callee to use this helper > to split them out into individual pieces. All true, but I guess this type of complexity would really complexify René's patch too much, so I am comfortable with the patch as-is. Ciao, Dscho
