From: Karthik Nayak Date: Mon, 08 Jun 2015 18:37:31 GMT Subject: Re: [PATCH v6 10/11] for-each-ref: introduce filter_refs() Message-ID: <5575E0EB.5030704@gmail.com> In-Reply-To: On 06/08/2015 11:45 PM, Junio C Hamano wrote: > Karthik Nayak writes: > >> +/* >> + * API for filtering a set of refs. The refs are provided and iterated >> + * over using the for_each_ref_fn(). The refs are stored into and filtered >> + * based on the ref_filter_cbdata structure. >> + */ >> +int filter_refs(int (for_each_ref_fn)(each_ref_fn, void *), struct ref_filter_cbdata *data) >> +{ >> + return for_each_ref_fn(ref_filter_handler, data); >> +} > > I do not think it is such a good idea to allow API callers to > specify for-each-ref-fn directly. See my message in an earlier > review. > I did read your previous message. I misunderstood some things. > > I also think ref_filter_cbdata is an implementation detail of > filter_refs and may not have to be exposed to the API callers. > It probably is more sensible for them to pass > > - an array of refs to receive filtered results (your ref_array thing) > - the criteria to use when filtering (your ref_filter thing) > This could be done. > > as two separate parameters to this function, together with other > parameters that lets you (meaning the implementation of filter_refs()) > to decide which for-each-ref iterator to call, e.g. do you want to > use raw iteration? do you want to iterate only over refs/heads? etc. > > In other words, the caller of this API should not have to know that > you (meaning the implementation of filter_refs()) are internally > using for_each_ref() API. > I'm a little confused about this, how exactly do you propose we go about doing something like this? I mean, usually the user of the API knows what exactly they want, like in tag.c, branch.c and for-each-ref.c But I'm not sure what you mean by "parameters that lets you (meaning the implementation of filter_refs()) to decide which for-each-ref iterator to call". A small example maybe? Thanks! -- Regards, Karthik