On Fri, Mar 21, 2014 at 02:03:41PM -0400, Brian Bourn wrote:
> > What do they do, what does the caller expect to see (do they get
> > something as return values? do they expect some side effects?)?
>
> so something like this would be better I'm assuming?
>
> Some basic sample API calls are found below, each of these would hold
> code to complete parsing and/or formatting the flags.
> Add_Opt_Group() - returns an OPT_CALLBACK with contains, merged,
> no-merged, or formatting which can be used in a commands options list.
>
> Execute_list()-the main call into the library and would pass into the
> library all of the necessary flags and arguments for parsing the
> request and executing it. This would accept the flags like
> -contain, with arguments such as the commit or pattern that is being
> searched for.
>
> The next four commands would be called by execute_list() to execute
> the original command with respect to the flags that are passed into
> this library.
> Parse_with_contains()
> Parse_with_merged()
> Parse_with_no_merged()
> Parse_with_formatting()
Think about how the callers would use them. Will git-branch just call
Parse_with_contains? If so, where would that call go? What arguments
would it take, and what would it do?
I don't think those calls are enough. We probably need:
1. Some structure to represent a "list of refs" and store its
intermediate state.
2. Some mechanism for telling that structure about the various
filters, sorters, and formatters we want to use (and this needs to
be hooked into the option-parsing somehow).
3. Some mechanism for getting the listed refs out of that structure,
formatting them, etc.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html