git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Eric Wong <normalperson@yhbt.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC] gitopt - command-line parsing enhancements
Date: Tue, 09 May 2006 13:28:23 -0700	[thread overview]
Message-ID: <7vr7332ba0.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20060509194825.GC3676@localdomain> (Eric Wong's message of "Tue, 9 May 2006 12:48:25 -0700")

Eric Wong <normalperson@yhbt.net> writes:

>> And scary, especially the "eat" macros are very scary.
>
> They look weird at first, but I think they help readability and
> maintainability once you get used to them.  They let you focus on the
> important part of the function while hiding the boring parts from you.
> Quite elegant, imho.

Sorry, there is no elegance to it as far as I can see.  A macro
invocation that creates a private function while it does not
look like a function definition is already bad, you cannot have
a comma in the stmt part, and the bare semicolons in the
parenthesised text look insane.

If your patch were like this, it would have been a bit easier
for me to understand what was going on during my first pass:

    static struct exec_args *ui_optparse
            (struct opt_spec *s, int ac, char **av, int *ac_p, int what)
    {
            struct exec_args *ea = one_arg(s, ac, av, ac_p);
            if (!ea) return NULL;
            switch (what) {
            case IGNORE_MISSING:
                    not_new = 1; break;
            case VERBOSE:
                    verbose = 1; break;
            case HELP:
                    usage(update_index_usage); break;
            }
            return nil_exec_args(ea);
    }

instead of

    gitopt_eat(opt_ignore_missing, not_new = 1;)
    gitopt_eat(opt_verbose, verbose = 1;)
    gitopt_eat(opt_h, usage(update_index_usage);)

Then, you would give an extra element in the table, and your
argument parsing/splitting routine passes that one to the
handler function:

    static const struct opt_spec update_index_ost[] = {
    ...
    { "ignore-missing", 0,	0, 0, ui_optparse, IGNORE_MISSING },
    { "verbose",	    0,	0, 0, ui_optparse, VERBOSE },
    { "help",	   'h',	0, 0, ui_optparse, HELP },
    { 0, 0 }

Another thing is I do not think we would want to make the
argument parsing into callback style interface like you did.  It
actively encourages the option variables to be global (you could
make it file scoped static but they are global nevertheless).
If you can make it an iterator style, it would be a lot easier
to see what is going on, I suspect.  Then you would not even
need the callback function pointers and small functions created
by magic eat() macros.

  reply	other threads:[~2006-05-09 20:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-09  5:06 [PATCH/RFC] gitopt - command-line parsing enhancements Eric Wong
2006-05-09  5:06 ` [PATCH 1/6] gitopt: a new command-line option parser for git Eric Wong
2006-05-09  5:06   ` [PATCH 2/6] update-index: convert to using gitopt Eric Wong
2006-05-09  5:06     ` [PATCH 3/6] ls-tree: convert to gitopt Eric Wong
2006-05-09  5:06       ` [PATCH 4/6] ls-files: convert to using gitopt Eric Wong
2006-05-09  5:06         ` [PATCH 5/6] gitopt: convert setup_revisions(), and diff_opt_parse() Eric Wong
2006-05-09  5:06           ` [PATCH 6/6] commit: allow --pretty= args to be abbreviated Eric Wong
2006-05-09  7:16           ` [PATCH 5/6] gitopt: convert setup_revisions(), and diff_opt_parse() Eric Wong
2006-05-11 20:19           ` Eric Wong
2006-05-09  9:08   ` [PATCH 1/6] gitopt: a new command-line option parser for git Timo Hirvonen
2006-05-09 12:58     ` Junio C Hamano
2006-05-09 19:39       ` Eric Wong
2006-05-09 19:18     ` Eric Wong
2006-05-09 20:10       ` Timo Hirvonen
2006-05-09 20:35         ` Junio C Hamano
2006-05-09 21:08           ` Timo Hirvonen
2006-05-09 21:11             ` Junio C Hamano
2006-05-09 21:31               ` Timo Hirvonen
2006-05-09  8:35 ` [PATCH/RFC] gitopt - command-line parsing enhancements Junio C Hamano
2006-05-09 19:48   ` Eric Wong
2006-05-09 20:28     ` Junio C Hamano [this message]
2006-05-09 21:14       ` Eric Wong

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=7vr7332ba0.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=normalperson@yhbt.net \
    /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 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 NNTP newsgroup(s).