On 2/3/06, Julian Foad <julianfoad@btopenworld.com> wrote:
> David James wrote:
> > In Ruby, if you put a space before an argument parenthesis, the
> > compiler emits a warning:
> > "warning: don't put space before argument parentheses"
> >
> > This warning isn't just a style suggestion. If you put spaces before
> > parentheses, the Ruby parser can choke. For example:
> > out << "some string".gsub (/[\s\n]*$/, "")
>
> Sorry, you'll have to explain if you want that "example" to demonstrate
> anything to those of us not familiar with Ruby syntax.
See the following thread:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/84103
I don't know why Ruby has problems with the extra space, but a Ruby
developer said: "It's caused by limitation of yacc parser generator
(and my brain). Please stand, and don't put spaces before argument
parentheses, please."
> > Perhaps we should follow the advice of the Ruby compiler, and avoid
> > the "space-before-paren" style? Ruby isn't the only language which has
> > trouble with the spaces. SWIG and the C-preprocessor have issues too.
>
> Tell us about SWIG's issues (briefly).
If you declare a SWIG macro using %define, you need to declare it
without spaces. You also need to avoid spaces when you use the macro.
This is similar to the restrictions of the C preprocessor. I expect
that other SWIG commands would have similar restrictions.
> As for the C preprocessor, I believe the only issue is that the definition of a
> macro taking parameters can't have a space before the open parenthesis; we
> already know and accept that so it's not an issue that causes any problems. Am
> I wrong?
No, that's right. The only issue here is that if we're reformatting
function calls, we'll have to be careful to avoid reformatting usages
of macros that look like function calls.
> > If we use the "no-space-before-paren" style, we'll be able to have
> > consistent function-call style throughout our entire body of source
> > code, including the SWIG bindings. That'd be a great thing.
>
> That extra bit of consistency would be no bad thing, but hardly "great", I think.
It's not a big deal, but it is nice for me, because if all of our code
uses the same style it will be easier for me to work.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 3 23:31:59 2006