From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Yao Zhao <zhaox383@umn.edu>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH] GSoC Change multiple if-else statements to be table-driven
Date: Fri, 14 Mar 2014 09:54:28 -0700 [thread overview]
Message-ID: <xmqqiorghgaj.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAPig+cRF_eQiGugR8TSks5ki375y-5wiQ7HWKyKRudJ5apd4cg@mail.gmail.com> (Eric Sunshine's message of "Thu, 13 Mar 2014 22:16:41 -0400")
Eric Sunshine <sunshine@sunshineco.com> writes:
> Thanks for the resubmission. Comments below.
Thanks, Eric, for helping so many micro exercises.
> On Thu, Mar 13, 2014 at 4:20 PM, Yao Zhao <zhaox383@umn.edu> wrote:
>> Subject: [PATCH] GSoC Change multiple if-else statements to be table-driven
>
> It's a good idea to let reviewers know that this is attempt 2. Do so
> by saying [PATCH v2]. Your next one will be [PATCH v3]. The -v option
> for "git format-email" can help.
Yao, I think Eric meant "git format-patch".
> When your patch is applied via "git am", text inside [...] gets
> stripped automatically. The "GSoC" tells email readers what this
> submission is about, but isn't relevant to the actual commit message.
> It should be placed inside [...]. For instance: [PATCH/GSoC v2].
So in short,
Subject: [PATCH/GSoC v2] branch.c: turn nested if-else logic to table-driven
or something.
>> + typedef struct PRINT_LIST {
> ...
>> + int b_origin;
>> + } PRINT_LIST;
We do not do ALL_CAPS names and tend not to introduce one-off
typedefs for struct. Instead we would just use "struct print_list"
throughout (if we were to indeed use such a new struct, that is).
>> + PRINT_LIST print_list[] = {
>> + {.print_str = _("Branch %s set up to track remote branch %s from %s by rebasing."),
>> + .arg2 = shortname, .arg3 = origin,
>> + .b_rebasing = 1, .b_remote_is_branch = 1, .b_origin = 1},
>> I am confused here: I use struct initializer and I am not sure if it's ok
>> because it is only supported by ANSI
> ...
> Indeed, you want to avoid named field initializers in this project and
> instead use positional initializers.
Correct.
> Translatable strings in an initializer should be wrapped with N_()
> instead of _(). You will still need to use _() later on when you
> reference the string from the table. See section 4.7 [2] of the GNU
> gettext manual for details.
Correct.
> An alternate approach might be to use a multi-dimensional array,
> where the boolean values of rebasing, remote_is_branch, and origin
> are keys into the array. This would allow you to pick out the
> correct PRINT_LIST entry directly (no looping), thus eliminating
> the need for those b_rebasing, b_remote_is_branch, and b_origin
> members.
Correct.
After seeing so many "table driven" submissions, I however tend to
agree with your earlier comment on another thread on this same
micro, where you said an nested if-else cascade that was rewritten
in a clearer way (sorry, I do not remember whose submission it was
offhand) may be the best answer to the "Would it make sense to make
the code table-driven?" question, even though I tentatively queued
d7ea7894 (install_branch_config(): simplify verbose messages logic,
2014-03-13) from Paweł on 'pu'.
Thanks for a review.
next prev parent reply other threads:[~2014-03-14 16:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 3:47 [PATCH] SoC 2014 MicroProject No.8:change multiple if-else statement to table-driven approach Yao Zhao
2014-03-12 9:21 ` Eric Sunshine
2014-03-13 20:20 ` [PATCH] GSoC Change multiple if-else statements to be table-driven Yao Zhao
2014-03-14 2:16 ` Eric Sunshine
2014-03-14 16:54 ` Junio C Hamano [this message]
2014-03-17 6:29 ` Eric Sunshine
2014-03-17 7:31 ` Junio C Hamano
2014-03-17 14:11 ` Michael Haggerty
2014-03-17 19:12 ` Junio C Hamano
2014-03-17 19:27 ` Eric Sunshine
2014-03-17 20:39 ` Quint Guvernator
2014-03-16 6:08 ` [PATCH/GSoC_v3] branch.c: turn nested if-else logic to table-driven Yao Zhao
2014-03-17 7:54 ` Eric Sunshine
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqiorghgaj.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.com \
--cc=zhaox383@umn.edu \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).