On Fri, Mar 21, 2014 at 2:07 PM, Jeff King <peff@xxxxxxxx> wrote: > 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. keeping some of my function calls to do the actual work I think I settled on this A possible API is given below, each of these would hold code to complete parsing and/or formatting the flags. There will be a struct in the library called refs_list() which when initialized will iterate through all the refs in a repository and add them to this list. there would be a function which would retrieve ref structs from that function. Get_ref_from_list()- which would return a single ref from the list. 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. This will then parse the refs_list using the four commands below to make, sort, filter, and format an output list which will then be printed or returned by this function. Any Call into the API from an outside source would call one of the previous two functions, all other commands in the API would be for internal use only, in order to simplify the process of calling into this library. The next four commands would be called by execute_list() to further format the refs_list with respect to the flags that are passed into this library. These would also take the additional arguments from execute_list() such as patterns to parse or which commit to filter out. these calls would modify the refs_list for eventual printing. Parse_list _with_contains() Parse_list_with_merged() Parse_list_with_no_merged() Format_list() of course this would still depend on deciding whether or not we want to return to the original command to print or if printing can be handled by the library itself. > -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