From: David Turner Date: Mon, 31 Aug 2015 19:54:17 GMT Subject: Re: [PATCH v6 1/2] worktree: add 'for_each_worktree' function Message-ID: <1441050857.25570.21.camel@twopensource.com> In-Reply-To: On Mon, 2015-08-31 at 15:03 -0400, Eric Sunshine wrote: > On Mon, Aug 31, 2015 at 2:44 PM, David Turner 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.