Re: [PATCH] merge: use string_list_split() in add_strategies()

Johannes Schindelin [off-list ref] 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.

Hi Junio,

On Mon, 8 Aug 2016, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

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