Re: [RFC] Re: Convert 'git blame' to parse_options()
On Mon, Jun 23, 2008 at 12:26:41PM +0000, Johannes Schindelin wrote:
Show 28 quoted lines
> Hi,
>
> On Mon, 23 Jun 2008, Pierre Habouzit wrote:
>
> > This "PARSE_OPT_IGNORE_UNRECOGNIZED" thing has been discussed many times
> > in the past, but it just doesn't fly.
> >
> > Though to help migrations we can probably introduce a new parse option
> > construct that would be a callback that is responsible for dealing with
> > "things" the upper level parser doesn't know about, something where the
> > callback could be:
> >
> > enum {
> > FLAG_ERROR = -1,
> > FLAG_NOT_FOR_ME,
> > FLAG_IS_FOR_ME,
> > FLAG_AND_VALUE_ARE_FOR_ME,
> > }
> >
> > int (*parse_opt_unknown_cb)(int shortopt, const char *longopt,
> > const char *value, void *priv);
>
> I believe that this is what Junio was talking about when he mentioned
> callbacks.
>
> However, I think it buys us more trouble than it saves us.
>
> Thinking about the recursive approach again, I came up with this POC: Well I proposed something like that in the past, and we believed it to
be too cumbersome. I can live with it well fwiw, but it doesn't solve
the issue of migrating a very complex option parsing chain to
parse-options well IMHO. THe big problem with diff and rev opt parsing
is that one you want to migrate _any_ of the commands, you have to
migrate _all_ of them, which is huge.
I believe the callback proposal as an _intermediate_ step allows a
better "upgrade" path. We can then converge to this proposal, or a big
fat macro, I don't care what we do in the end, but as one guy that
migrated quite a few commands, I care about the work being doable in an
incremental way.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Pierre Habouzit <madcoder@debian.org>