[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: Yellow <d.s_at_daniel.shahaf.name>
Date: Mon, 2 May 2011 23:24:34 +0300

Hyrum K Wright wrote on Mon, May 02, 2011 at 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.
>

There is a third option: (foo->bar)(...).

> -Hyrum
Received on 2011-05-02 22:28:36 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.