You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2011/05/02 21:52:45 UTC
Re: svn commit: r1098610 - /subversion/trunk/subversion/libsvn_delta/editor.c
On Mon, May 2, 2011 at 10:55, <hw...@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.
Cheers,
-g
Re: svn commit: r1098610 - /subversion/trunk/subversion/libsvn_delta/editor.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, May 3, 2011 at 17:20, C. Michael Pilato <cm...@collab.net> wrote:
> On 05/03/2011 09:10 AM, Julian Foad wrote:
>> FWIW, personally I prefer the foo->bar(...) style.
>
> As do I. </bikeshed>
>
+1.
--
Ivan Zhakov
Re: svn commit: r1098610 - /subversion/trunk/subversion/libsvn_delta/editor.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/03/2011 09:10 AM, Julian Foad wrote:
> FWIW, personally I prefer the foo->bar(...) style.
As do I. </bikeshed>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1098610 -
/subversion/trunk/subversion/libsvn_delta/editor.c
Posted by Julian Foad <ju...@wandisco.com>.
On Mon, 2011-05-02, Yellow wrote:
> 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 <gs...@gmail.com> wrote:
> > > On Mon, May 2, 2011 at 10:55, <hw...@apache.org> wrote:
> > >> 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)(...).
The only pertinent commentary I can find on this topic is a note in the
C Rationale: section 3.3.2.2 for C89
<http://www.lysator.liu.se/c/rat/c3.html#3-3-2-2> or the same thing in
section 6.5.2.2 for C99 (see <http://www.open-std.org/jtc1/sc22/wg14/>).
We have all three styles in the code base, and some rough searching
yields the following counts:
$ grep -i -- "->[a-z_][a-z0-9_]*(" subversion/{*,*/*}/*.c
926 # foo->bar(...)
$ grep -i -- "^[^*]*->[a-z_][a-z0-9_]*)(" subversion/{*,*/*}/*.c
46 # (foo->bar)(...)
$ grep -i -- "^[^*]*\*.*->[a-z_][a-z0-9_]*)(" subversion/{*,*/*}/*.c
98 # (*foo->bar)(...)
and it looks like we have a broadly similar spread of function pointer
calling styles where there is no "struct->" dereferencing going on.
FWIW, personally I prefer the foo->bar(...) style.
- Julian
Re: svn commit: r1098610 -
/subversion/trunk/subversion/libsvn_delta/editor.c
Posted by Yellow <d....@daniel.shahaf.name>.
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 <gs...@gmail.com> wrote:
> > On Mon, May 2, 2011 at 10:55, <hw...@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
Re: svn commit: r1098610 - /subversion/trunk/subversion/libsvn_delta/editor.c
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Tue, May 3, 2011 at 4:35 PM, Greg Stein <gs...@gmail.com> wrote:
>
> On May 2, 2011 4:00 PM, "Hyrum K Wright" <hy...@hyrumwright.org> wrote:
>>
>> On Mon, May 2, 2011 at 2:52 PM, Greg Stein <gs...@gmail.com> wrote:
>> > On Mon, May 2, 2011 at 10:55, <hw...@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.
>
> Looks like opinion is to leave your change!
Will do (but I'll also refrain from gratuitous changes like this in
the future :)
-Hyrum
Re: svn commit: r1098610 - /subversion/trunk/subversion/libsvn_delta/editor.c
Posted by Greg Stein <gs...@gmail.com>.
On May 2, 2011 4:00 PM, "Hyrum K Wright" <hy...@hyrumwright.org> wrote:
>
> On Mon, May 2, 2011 at 2:52 PM, Greg Stein <gs...@gmail.com> wrote:
> > On Mon, May 2, 2011 at 10:55, <hw...@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.
Looks like opinion is to leave your change!
Cheers,
-g
Re: svn commit: r1098610 - /subversion/trunk/subversion/libsvn_delta/editor.c
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, May 2, 2011 at 2:52 PM, Greg Stein <gs...@gmail.com> wrote:
> On Mon, May 2, 2011 at 10:55, <hw...@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