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

Re: svn commit: r1098610 - /subversion/trunk/subversion/libsvn_delta/editor.c

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Mon, 2 May 2011 15:00:45 -0500

On Mon, May 2, 2011 at 2:52 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Mon, May 2, 2011 at 10:55,  <hwright_at_apache.org> wrote:
>> Author: hwright
>> Date: Mon May  2 14:55:34 2011
>> New Revision: 1098610
>>
>> URL: http://svn.apache.org/viewvc?rev=1098610&view=rev
>> Log:
>> Use our "typical" function call syntax when using function pointers in the
>> delta editor.
>>
>> One of the things that has always puzzled me is why (*func_ptr)(args) and
>> func_ptr(args) are equivalent.  While this remains an enigma, I much prefer
>> the consistency offered by using the same syntax throughout our code base,
>> and since this appears to be the odd file out, it get's the change.
>
> I use the (*foo->bar)(...) form because the operator precedence and
> binding is clearer. foo->bar(...) kind seems like bar(..) is getting
> called, then something weird is going on with foo->. Yes, it is true
> that foo->$result does not make sense, BUT: the brain recognizes that
> *after* parsing bar(...) first. So when you see code like this, your
> brain does a two-step. It just isn't smooth reading. Thus, the use of
> (*foo->bar)(...). There is no pause in the brain's parsing of what is
> actually happening there.
>
> My preference would be to revert this change, to keep the previous
> readability. We've generally allowed slight style variances as long as
> a single file is consistent.

Fine by me, though I've never noticed the mental do-si-do you describe
above. At the end of the day it's just a bikeshed, so I'll give it a
bit to allow others to weigh in.

-Hyrum
Received on 2011-05-02 22:01:15 CEST

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.