On 16.04.2013 15:29, C. Michael Pilato wrote:
> On 04/16/2013 08:33 AM, julianfoad_at_apache.org wrote:
>> Author: julianfoad
>> Date: Tue Apr 16 12:33:08 2013
>> New Revision: 1468395
>>
>> URL: http://svn.apache.org/r1468395
>> Log:
>> Introduce a typedef 'svn_fs_freeze_func_t', for source code regularity and
>> symmetry with 'svn_repos_freeze_func_t'. It might also be useful for the
>> SWIG bindings.
> When callback signatures are this generic, is there any good reason to
> proliferate their unique definition? Users don't really get any benefit by
> their having a unique type name that I can surmise. And every time we
> introduce a new callback type, the SWIG bindings must be tinkered with to
> support it.
>
> May I suggest that we either:
>
> * eliminate svn_repos_freeze_func_t, and simply make svn_repos_freeze() also
> accept this new svn_fs_freeze_func_t, or
>
> * eliminate both of those callback types, and introduce (in svn_types.h) an
> uber-generic callback that accepts a void * baton and a scratch_pool and is
> used for both svn_repos_freeze() and svn_fs_freeze(), plus any future such
> generic callback scenarios
>
> ?
What's the point of that?
I think it's better to have explicit typedefs for every specific kind of
callback, even if the actual type signatures are the same. It adds no
burden to the callback implementor (after all, they just have to define
a callback function in any case), and it does add a teensy bit of extra
self-documenting goodness to the signatures of the functions that accept
callbacks.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-04-16 17:30:00 CEST