So I guess I can disable the warnings by changing the warning level, but
it is mind boggling that I would need to. I would expect this type of
a) not be even shown for how I am using it, and b) that it wouldn’t show
up when running in production by default, only in debug. If I disable
these, then I might not get other ACTUAL errors in my logs I presume.
These are the lines of code that generate the warnings:
xml.rating ( creative.creative_ratings_count > 0 ?
“%1.1f”%(creative.creative_ratings_sum.to_f /
creative.creative_ratings_count) : 0)
xml.thumbnail (creative.processed_at != nil ? “#{creative.thumbnail}” :
‘unprocessed.png’)
xml.default_format_filename (creative.processed_at != nil ?
“#{creative.default_format_filename}” : ‘unprocessed.png’)
Why can’t I use ( ? : ) as a grouping operator for my inline conditional
like this without getting inundated with error messages?
Thanks.
[Tue Jun 03 18:09:33 2008] [error] [client 127.0.0.1] FastCGI: server
“/var/www/html/klondike/public/dispatch.fcgi” stderr: /var/w
ww/html/klondike/public/…/config/…/vendor/plugins/interact/config/…/…/…/…/app/controllers/api_controller.rb:617:
warning: do
n’t put space before argument parentheses
[Tue Jun 03 18:09:33 2008] [error] [client 127.0.0.1] FastCGI: server
“/var/www/html/klondike/public/dispatch.fcgi” stderr: /var/w
ww/html/klondike/public/…/config/…/vendor/plugins/interact/config/…/…/…/…/app/controllers/api_controller.rb:618:
warning: do
n’t put space before argument parentheses
[Tue Jun 03 18:09:33 2008] [error] [client 127.0.0.1] FastCGI: server
“/var/www/html/klondike/public/dispatch.fcgi” stderr: /var/w
ww/html/klondike/public/…/config/…/vendor/plugins/interact/config/…/…/…/…/app/controllers/api_controller.rb:619:
warning: do
n’t put space before argument parentheses
because you should be doing xml.rating(…) not xml.rating (…) If
you don’t then in a future version of ruby it will probably all stop
working.,
This is a pure ruby thing so it’s not going via Rails’ logger (and the
associated log threshold)
because you should be doing xml.rating(…) not xml.rating (…) If
you don’t then in a future version of ruby it will probably all stop
working.,
This is a pure ruby thing so it’s not going via Rails’ logger (and the
associated log threshold)
Fred
That doesn’t really make sense IMO… either parans are a grouping
operator or they are not. And the reason I add a space is because I have
gotten errors in the past without them, as ruby will misparse the
tertiary conditional operator. It obviously works fine as is, just
spamming error messages…I can’t imagine that making such a huge impact
on the lexer.
If ruby were to say: All function calls must use parans, like C, AS, JS,
Java, etc. I would understand (but still be annoyed lol). But they
specifically allow parameters without.
The point being:
Say I want to change my XMLBuilder code from:
xml.something ( is_true == true ? db_row.datefield : “1972” )
to
xml.something ( is_true == true ? db_row.datefield : “1972” ).to_date
Should the resulting code be:
xml.something(is_true == true ? db_row.datefield : “1972”).to_date
cause I’m pretty sure that would fall over, and certainly doesn’t look
correct or is the ‘new correct way’ to apply yet another set of parans?
Or if I want to do:
some_two_arg_method (is_true == true ? db_row.datefield : “1972”),
“Second arg”
They are a grouping operator and they can be used for a function call
That’s the ambiguity: does to date apply to ( is_true == true ?
db_row.datefield : “1972” ) or to the return value of xml.something ?
xml.something(( is_true == true ? db_row.datefield : “1972” ).to_date)
is unambiguous
99% of the time you get to leave out the punctuation and ruby gets it
right, but sometimes it’s ambiguous and you need to lend a helping hand
Fred
Why shouldn’t that work without complaint?
again, ambiguous: is that a function call taking 2 arguments, or 2
expression separated by a comma ?
Fred
The point is it works exactly how I expect it to now, and is
unambiguous, it just spams the logs 20 times a second. Ie. adding the
space removes the ambiguity, yet ruby wants to throw a fit. It just
seems so inelegant to be forced to add additional parans for this
relatively common case.
But then I also want to throw YAML into the street to be run over for
using '" as multi-line quote delimiters.
That doesn’t really make sense IMO… either parans are a grouping
operator or they are not. And the reason I add a space is because I
have
gotten errors in the past without them, as ruby will misparse the
tertiary conditional operator. It obviously works fine as is, just
spamming error messages…I can’t imagine that making such a huge
impact
on the lexer.
They are a grouping operator and they can be used for a function call
That’s the ambiguity: does to date apply to ( is_true == true ?
db_row.datefield : “1972” ) or to the return value of xml.something ?
xml.something(( is_true == true ? db_row.datefield : “1972” ).to_date)
is unambiguous
99% of the time you get to leave out the punctuation and ruby gets it
right, but sometimes it’s ambiguous and you need to lend a helping hand
Fred
Why shouldn’t that work without complaint?
again, ambiguous: is that a function call taking 2 arguments, or 2
expression separated by a comma ?
Fred
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.