Stefan Beller <sbel...@google.com> 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.
