Subject: Re: [PATCH v6 1/2] worktree: add 'for_each_worktree' function

From: David Turner <[email-masked]>
Date: Mon, 31 Aug 2015 15:54:17 -0400

On Mon, 2015-08-31 at 15:03 -0400, Eric Sunshine wrote:
> On Mon, Aug 31, 2015 at 2:44 PM, David Turner <[email-masked]> 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.