New to Ruby. Having trouble with ternary statements.
I am used to a language that allows these two forms:
test ? trueStuff
test ? trueStuff | falseStuff
While I have yet to find a reference that explicitly states this, it
would appear that ternary statement in Ruby is not allowed to exclude
the :, as without it I get an "unexpected '\n'" error statement.
That's working for most cases, however, whenever such a line appears in
IF statements, it generates another set of errors.
if (...whatever...)
...do some stuff...
$debug ? $devLog.info("bla bla bla") :
else
...do other stuff...
$debug ? $devLog.info("yadda yadda") :
end
I get "unexpected kELSE" and "unexpected kEND" syntax errors.
Hard to comprehend what can be so tricky about a simple ternary
statement. Indeed it is assumed to be so simple that the Programming
Ruby book offers no details for its use, yet clearly there are some
rules that need to be followed.
The ternary operator is not used very often, Ruby offers a different
way to do what you try.
do_stuff if test
do_stuff unless test
are both valid forms.
You cannot omit the third parameter from the ternary (that's why it
has this name, after all)
So if you want to make it work you have to:
test ? do_stuff : nil
Hope this helps, more information on the ruby quickref:
···
On 10/7/07, Greg Willits <lists@gregwillits.ws> wrote:
New to Ruby. Having trouble with ternary statements.
I am used to a language that allows these two forms:
test ? trueStuff
test ? trueStuff | falseStuff
While I have yet to find a reference that explicitly states this, it
would appear that ternary statement in Ruby is not allowed to exclude
the :, as without it I get an "unexpected '\n'" error statement.
Ok, fine, so I can write something like this:
$debug ? $devLog.info("bla bla bla") :
That's working for most cases, however, whenever such a line appears in
IF statements, it generates another set of errors.
if (...whatever...)
...do some stuff...
$debug ? $devLog.info("bla bla bla") :
else
...do other stuff...
$debug ? $devLog.info("yadda yadda") :
end
I get "unexpected kELSE" and "unexpected kEND" syntax errors.
Hard to comprehend what can be so tricky about a simple ternary
statement. Indeed it is assumed to be so simple that the Programming
Ruby book offers no details for its use, yet clearly there are some
rules that need to be followed.
The ternary operator is not used very often, Ruby offers a different
way to do what you try.
do_stuff if test
do_stuff unless test
Ah, OK. Strange structure. (rhetorical Q:) Why read through all the
do_stuff if it isn't going to matter by the time you get the IF?
I guess I'll switch to that if it is more customary.
You cannot omit the third parameter from the ternary (that's why it
has this name, after all)
OK, thanks for confirming that. Sure, name makes sense, but so does
allowing a form w/o the ELSE (which is what I am accustomed to doing).
So if you want to make it work you have to:
test ? do_stuff : nil
Tried that early on and still got errors, but after experimenting more I
see now its beacuse I only tried that in a few places rather than in all
ternaries in the script. Once I did it for all, the script worked.
You might enjoy the "short-circuiting" operators instead:
condition && ifitstruedothis()
or
condition || ifitsfalsedothis()
these are like C. Cheers, -r.
···
On 10/6/07, Greg Willits <lists@gregwillits.ws> wrote:
> The ternary operator is not used very often, Ruby offers a different
> way to do what you try.
>
> do_stuff if test
> do_stuff unless test
Ah, OK. Strange structure. (rhetorical Q:) Why read through all the
do_stuff if it isn't going to matter by the time you get the IF?
I guess I'll switch to that if it is more customary.
> You cannot omit the third parameter from the ternary (that's why it
> has this name, after all)
OK, thanks for confirming that. Sure, name makes sense, but so does
allowing a form w/o the ELSE (which is what I am accustomed to doing).
> So if you want to make it work you have to:
> test ? do_stuff : nil
Tried that early on and still got errors, but after experimenting more I
see now its beacuse I only tried that in a few places rather than in all
ternaries in the script. Once I did it for all, the script worked.
--
"We can try to do it by breaking free of the mental prison of
separation and exclusion and see the world in its interconnectedness
and non-separability, allowing new alternatives to emerge." -- after
Vandana Shiva
Rhetorical semi-answer (by argument to consequences):
Ruby, unlike some (most?) languages, *always* requires an end for its if
statements; that is to say, you can't just type
if debug_mode then
puts "Got to line 123"
do_something important
You have to have an "end" for the if.
Allowing the form
puts "Got to line 123" if debug_mode
do_something important
lets you have more compact code, at the potential expense of readability.
I believe the construct came from Perl, but I'm not sure that's the first
place it ever appeared.
For readability's sake, I usually follow the guideline "don't use that form
unless the main body of code is the common path". That is, I wouldn't use
it for debug statements, because they're usually not executed, so you spend
a lot of time reading code and then realizing it didn't get executed after
all. I might use it for something like:
Ah, OK. Strange structure. (rhetorical Q:) Why read through all the
do_stuff if it isn't going to matter by the time you get the IF?
Rhetorical semi-answer (by argument to consequences):
Allowing the form
puts "Got to line 123" if debug_mode
do_something important
lets you have more compact code, at the potential expense of
readability.
For readability's sake, I usually follow the guideline "don't use that
form
unless the main body of code is the common path". That is, I wouldn't
use
it for debug statements, because they're usually not executed, so you
spend
a lot of time reading code and then realizing it didn't get executed
after all.
Thanks for piping up and saying "don't use that." I agree
All this is exactly why
condition ? do_stuff
is very useful. Compact. Readable. Logical. Efficient. Even if it is not
a true ternary.
I have plenty enough experience in dynamic, reflective, OO programming,
to figure out the bulk of Ruby, but Ruby does seems to have its own way
of approaching some things compared to my experience.
I know there's a book called The Ruby Way -- does it tend to address
these kinds of usage idioms where "method 2 out of 4 tends to be the way
most people do it"?
-- gw
···
On Sun, 7 Oct 2007 03:44:20 +0900, Greg Willits wrote:
Many, and I'd highly recommend the book. But Ruby's a young language, and
idioms go in and out of fashion, especially in the Rails community, which
(for better or worse) makes up a large part of the newest Ruby population.
The newsgroups and reading other people's code are the best two ways I've
found to learn idioms - that, and posting my own code here in a "how would
you do this better?" thread.
···
On Sun, 7 Oct 2007 04:28:34 +0900, Greg Willits wrote:
I know there's a book called The Ruby Way -- does it tend to address
these kinds of usage idioms where "method 2 out of 4 tends to be the way
most people do it"?
--
Jay Levitt |
Boston, MA | My character doesn't like it when they
Faster: jay at jay dot fm | cry or shout or hit. http://www.jay.fm | - Kristoffer
I have plenty enough experience in dynamic, reflective, OO programming,
to figure out the bulk of Ruby, but Ruby does seems to have its own way
of approaching some things compared to my experience.
There wouldn't be much point in having it if it didn't It's a
relatively easy language to learn, a lot of experienced programmers
find, but there's definitely some learning involved, as with any
language. Hopefully you'll find it interesting and worthwhile.
David
--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!
I know there's a book called The Ruby Way -- does it tend to address
these kinds of usage idioms where "method 2 out of 4 tends to be the way
most people do it"?
Jay Levitt wrote:
Many, and I'd highly recommend the book. But Ruby's a young language,
and idioms go in and out of fashion, especially in the Rails community,
which (for better or worse) makes up a large part of the newest Ruby
population.
Cool, I'll get the book. I'm overseeing a Rails project, so I need to
have at least a working familiarity with both, though I'm more
interested in learning Ruby to a deeper level than Rails. (I've been
doing all my own work in another language & my own framework). However,
I'm also going to be doing a bunch of automated / CLI data aggregation
and misc utility work which I chose Ruby for -- mostly to force the
issue of familiarity.
I have plenty enough experience in dynamic, reflective, OO programming,
to figure out the bulk of Ruby, but Ruby does seems to have its own way
of approaching some things compared to my experience.
David A. Black wrote:
There wouldn't be much point in having it if it didn't
Heh. True.
Hopefully you'll find it interesting and worthwhile.
I'm sure I will. My first code has been a simple web crawler. After
getting over a few little syntax humps, it's been fairly easy to
implement.
The Ruby Way is an excellent book for experienced programmers to get a good look at many different things in Ruby.
But there are lots of good Ruby books! You should probably head down to a bookstore that carries them and browse them for the one(s) that will serve you best.
I'm trying to collect them all. I just wish they came with collector's cards or something collectible.
(that might not be a bad idea to create a market for outdated (in the future) computer books.
On Sun, 7 Oct 2007 10:24:35 +0900, John Joyce wrote:
(that might not be a bad idea to create a market for outdated (in the future) computer books.
I know entire stores that carry nothing but outdated computer books.
Barnes and Noble, Borders...
(Looking at my months-old book for GIMP 2.4....)
--
John W. Kennedy
"The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of the Conservatives is to prevent the mistakes from being corrected."
-- G. K. Chesterton
