From: shejialuo <shejialuo@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 4/7] string-list: optionally trim string pieces split by string_list_split*()
Date: Sat, 2 Aug 2025 09:51:15 +0800 [thread overview]
Message-ID: <aI1vEzuD2DeiFSzW@mbp> (raw)
In-Reply-To: <xmqqa54iljw1.fsf@gitster.g>
On Fri, Aug 01, 2025 at 04:09:02PM -0700, Junio C Hamano wrote:
> shejialuo <shejialuo@gmail.com> writes:
>
> > I agree with you that we would introduce another variable. However, the
> > thing I quite dislike is that we do ltrim inside the current function
> > and we do rtrim inside `append_one`.
>
> Your "quite dislike" does not matter unless backed by a reason why
> it is not good, and for that, you need to think a bit deeper. Then
> you will hopefully appreciate why the current arrangement is more
> optimal ;-)
>
> There is a clear separation of tasks between this caller-callee
> pair. The caller is responsible for finding where the current token
> ends, and the callee is responsible for massaging the current token
> into the resulting list.
>
> But ltrim needs to be done in the caller for this to be efficient.
>
> Imagine the case where you want to allow both non-empty and trim
> behaviour at the same time, and use a whitespace character as
> delimiter. If your token has leading whitespaces, instead of
> chopping them into zero-length ranges and feeding it to append_one()
> one by one, only to have them discarded (due to non-empty being
> set), ltrimming in the caller before it decides where the next token
> (i.e. "end") starts is far more efficient. It may be more
> conceptually cleaner, but cleanliness is more subjective ;-)
>
Yes, I agree. Thanks for the wonderful explanation.
> > My thinking is that we should handle the [p, end) string in the same
> > place.
>
> Again this sounds no more than a subjective "quite dislike". Is
> there a reason why anybody would want to insist these two things be
> done at the same location?
>
> You could satisfy the subjective "same place requirement" by
> inlining the helper function into its sole caller and still keep the
> current arrangement to ltrim before finding "end", of course. But
> at that point, I would have to say that it is a tail wagging the
> dog. You are making the code worse by destroying the caller-callee
> division of responsibilities, only to satisfy a subjetive "quite
> dislike" criteria.
>
I get your point. In the later review, I think I should avoid commenting
things using a subjetive idea. Really thanks for your suggestion.
Thanks,
next prev parent reply other threads:[~2025-08-02 1:51 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-31 6:39 [PATCH 0/5] string_list_split*() updates Junio C Hamano
2025-07-31 6:39 ` [PATCH 1/5] string-list: report programming error with BUG Junio C Hamano
2025-07-31 19:33 ` Eric Sunshine
2025-07-31 22:16 ` Junio C Hamano
2025-07-31 6:39 ` [PATCH 2/5] string-list: align string_list_split() with its _in_place() counterpart Junio C Hamano
2025-07-31 19:36 ` Eric Sunshine
2025-07-31 6:39 ` [PATCH 3/5] string-list: unify string_list_split* functions Junio C Hamano
2025-07-31 6:39 ` [PATCH 4/5] string-list: optionally trim string pieces split by string_list_split() Junio C Hamano
2025-07-31 6:39 ` [PATCH 5/5] diff: simplify parsing of diff.colormovedws Junio C Hamano
2025-07-31 19:45 ` Eric Sunshine
2025-07-31 22:45 ` [PATCH v2 0/7] string_list_split*() updates Junio C Hamano
2025-07-31 22:46 ` [PATCH v2 1/7] string-list: report programming error with BUG Junio C Hamano
2025-07-31 22:46 ` [PATCH v2 2/7] string-list: align string_list_split() with its _in_place() counterpart Junio C Hamano
2025-08-01 2:33 ` shejialuo
2025-08-01 3:43 ` Junio C Hamano
2025-08-01 3:55 ` shejialuo
2025-08-01 23:10 ` Junio C Hamano
2025-07-31 22:46 ` [PATCH v2 3/7] string-list: unify string_list_split* functions Junio C Hamano
2025-08-01 3:00 ` shejialuo
2025-07-31 22:46 ` [PATCH v2 4/7] string-list: optionally trim string pieces split by string_list_split*() Junio C Hamano
2025-08-01 3:18 ` shejialuo
2025-08-01 3:47 ` Junio C Hamano
2025-08-01 4:04 ` shejialuo
2025-08-01 23:09 ` Junio C Hamano
2025-08-02 1:51 ` shejialuo [this message]
2025-08-01 8:47 ` Patrick Steinhardt
2025-08-01 16:26 ` Junio C Hamano
2025-07-31 22:46 ` [PATCH v2 5/7] diff: simplify parsing of diff.colormovedws Junio C Hamano
2025-08-01 8:47 ` Patrick Steinhardt
2025-07-31 22:46 ` [PATCH v2 6/7] string-list: optionally omit empty string pieces in string_list_split*() Junio C Hamano
2025-07-31 22:54 ` Eric Sunshine
2025-08-01 3:33 ` shejialuo
2025-08-01 8:47 ` Patrick Steinhardt
2025-08-01 16:38 ` Junio C Hamano
2025-07-31 22:46 ` [PATCH v2 7/7] string-list: split-then-remove-empty can be done while splitting Junio C Hamano
2025-08-01 8:47 ` Patrick Steinhardt
2025-08-01 22:04 ` [PATCH v3 0/7] string_list_split*() updates Junio C Hamano
2025-08-01 22:04 ` [PATCH v3 1/7] string-list: report programming error with BUG Junio C Hamano
2025-08-01 22:04 ` [PATCH v3 2/7] string-list: align string_list_split() with its _in_place() counterpart Junio C Hamano
2025-08-02 8:22 ` Jeff King
2025-08-02 16:34 ` Junio C Hamano
2025-08-02 18:38 ` Jeff King
2025-08-01 22:04 ` [PATCH v3 3/7] string-list: unify string_list_split* functions Junio C Hamano
2025-08-01 22:04 ` [PATCH v3 4/7] string-list: optionally trim string pieces split by string_list_split*() Junio C Hamano
2025-08-02 8:26 ` Jeff King
2025-08-02 16:38 ` Junio C Hamano
2025-08-02 18:39 ` Jeff King
2025-08-01 22:04 ` [PATCH v3 5/7] diff: simplify parsing of diff.colormovedws Junio C Hamano
2025-08-01 22:04 ` [PATCH v3 6/7] string-list: optionally omit empty string pieces in string_list_split*() Junio C Hamano
2025-08-01 22:04 ` [PATCH v3 7/7] string-list: split-then-remove-empty can be done while splitting Junio C Hamano
2025-08-03 6:52 ` [PATCH v4 0/7] string_list_split*() updates Junio C Hamano
2025-08-03 6:52 ` [PATCH v4 1/7] string-list: report programming error with BUG Junio C Hamano
2025-08-03 6:52 ` [PATCH v4 2/7] string-list: align string_list_split() with its _in_place() counterpart Junio C Hamano
2025-08-03 6:52 ` [PATCH v4 3/7] string-list: unify string_list_split* functions Junio C Hamano
2025-08-03 6:52 ` [PATCH v4 4/7] string-list: optionally trim string pieces split by string_list_split*() Junio C Hamano
2025-08-03 6:52 ` [PATCH v4 5/7] diff: simplify parsing of diff.colormovedws Junio C Hamano
2025-08-03 6:52 ` [PATCH v4 6/7] string-list: optionally omit empty string pieces in string_list_split*() Junio C Hamano
2025-08-03 6:52 ` [PATCH v4 7/7] string-list: split-then-remove-empty can be done while splitting Junio C Hamano
2025-08-04 6:24 ` [PATCH v4 0/7] string_list_split*() updates Patrick Steinhardt
2025-08-03 6:52 ` [PATCH v3 00/12] do not overuse strbuf_split*() Junio C Hamano
2025-08-03 6:52 ` [PATCH v3 01/12] wt-status: avoid strbuf_split*() Junio C Hamano
2025-08-03 6:52 ` [PATCH v3 02/12] clean: do not pass strbuf by value Junio C Hamano
2025-08-03 6:52 ` [PATCH v3 03/12] clean: do not use strbuf_split*() [part 1] Junio C Hamano
2025-08-03 6:52 ` [PATCH v3 04/12] clean: do not pass the whole structure when it is not necessary Junio C Hamano
2025-08-03 6:52 ` [PATCH v3 05/12] clean: do not use strbuf_split*() [part 2] Junio C Hamano
2025-08-03 6:52 ` [PATCH v3 06/12] merge-tree: do not use strbuf_split*() Junio C Hamano
2025-08-03 6:52 ` [PATCH v3 07/12] notes: " Junio C Hamano
2025-08-03 6:53 ` [PATCH v3 08/12] config: do not use strbuf_split() Junio C Hamano
2025-08-03 6:53 ` [PATCH v3 09/12] environment: do not use strbuf_split*() Junio C Hamano
2025-08-03 6:53 ` [PATCH v3 10/12] sub-process: " Junio C Hamano
2025-08-03 6:53 ` [PATCH v3 11/12] trace2: trim_trailing_newline followed by trim is a no-op Junio C Hamano
2025-08-03 6:53 ` [PATCH v3 12/12] trace2: do not use strbuf_split*() Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aI1vEzuD2DeiFSzW@mbp \
--to=shejialuo@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.