On Mon, Aug 31, 2015 at 2:44 PM, David Turner <dturner@xxxxxxxxxxxxxxxx> 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. -- 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