On Mon, 2015-08-31 at 15:03 -0400, Eric Sunshine wrote: > On Mon, Aug 31, 2015 at 2:44 PM, David Turner <dtur...@twopensource.com> > wrote: > > On Mon, 2015-08-31 at 01:11 -0400, Eric Sunshine wrote: > >> Stepping back a bit, is a for-each-foo()-style interface desirable? > >> This sort of interface imposes a good deal of complexity on callers, > >> demanding a callback function and callback data (cb_data), and is > >> generally (at least in C) more difficult to reason about than other > >> simpler interfaces. Is such complexity warranted? > >> > >> An alternate, much simpler interface would be to have a function, say > >> get_worktrees(), return an array of 'worktree' structures to the > >> caller, which the caller would iterate over (which is a common > >> operation in C, thus easily reasoned about). > >> > >> The one benefit of a for-each-foo()-style interface is that it's > >> possible to "exit early", thus avoiding the cost of interrogating > >> meta-data for worktrees in which the caller is not interested, > >> however, it seems unlikely that there will be so many worktrees linked > >> to a repository for this early exit to translate into any real > >> savings. > > > > The other benefit is that there is no need to worry about deallocating > > the list. But that might be too minor to worry about. > > Probably. The burden of having to deallocate the returned array seems > quite minor compared to the complexity of the callback function > approach. > > Also, unstated but implied with the suggestion of a get_worktrees() > function was that there would be a corresponding free_worktrees() > function to make cleanup easy.
That's fine with me. Sorry for leading you down the wrong path, Michael. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
