Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 30, 2017, 18:47 UTC
- Message-ID
- <xmqqo9t5qpma.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <CAGZ79kbu2hqc41eBk_AtoeTviJGT4TTV7M6cYp0h4q=gJs2wRg@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
Show 8 quoted lines
> 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.