On Fri, Jun 30, 2017 at 11:47 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> Ok, let me redo the patch to have fndata at the front. >> >> Looking at other places (that have a similar mechanism mechanically, >> but are semantically different), such as the callback functions for >> the diff machinery, we have the user provided pointer at the end >> of the list. But that is because the diff_options are the objects that >> should be in front row (they are bound to the callback more than >> some caller needed data). > > Quite honestly, I do not care too deeply about an API specific to a > particular area like "diff" that passes its "configuration" data > that everybody in the API knows, i.e. diff_options. If the > convention for ordinary functions in the API is to pass that in a > particular location in the parameter list, I would think it is good > for a application-supplied callback function to follow that pattern. > After all, it is to configure the behaviour of the "diff" and the > caller-supplied callback could have been part of a (hypothetically > richer) API implementation. > > But I view a comparison function that is given to hashmap that is > supplied by the caller a bit differently. It is not about > "hashing", so the reason to have the data close to function pointer > is stronger there. Yes I agree with that, I forgot to say so. I just cited the example to see if we have a preference in the project already and that's about it, but as it is different, we can put the fndata first. Thanks, Stefan
