[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 5429 - trunk/subversion/include

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-03-24 11:02:22 CET

Greg Stein wrote:

>On Sun, Mar 23, 2003 at 08:57:18PM +0100, Branko ??ibej wrote:
>
>
>>...
>>
>>
>>>+typedef svn_error_t *(*svn_repos_commit_callback_t) (
>>>+ svn_revnum_t new_revision,
>>>+ const char *date,
>>>+ const char *author,
>>>+ void *baton);
>>>
>>>
>>Yes, it is a pattern used elsewhere, but the meaning is exactly the same
>>-- and now the code is less readable. We also seem to be using the
>>"(*funptr)(args)" syntax instead of the more natural "funcptr(args)" for
>>calls through pointers to functions.
>>
>>
>
>I disagree on both parts. I find the above declaration and the (*funptr)
>usage to be more readable.
>
>For example, when I see:
>
> notify_func(arg1, arg2, arg3)
>
>it is hard to figure out whether notify_func() is a function or is a
>variable pointing to a function.
>
>

And *you* are a Python fan? :-)

It's entirely unimportant to the meaning of the code whether notify_func
is a variable or a function name. Using different syntax to
differentiate the two is the same sort of wrong-headedness as using
Hungarian notation to denote variable type. What if you change the code
from using a function to using a function pointer? Do you go through the
code and change all instances of foo() to (*foo)()?

It's important what a symbol *does*, not what it *is*. Do not obfuscate
the meaning of the code by mucking with syntax based on symbol types.
Might as well add (void) casts to all function calls where we ignore the
return value, or explicit casts from void* to other pointer types.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 24 11:06:20 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.