Ternary Usage

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.

Any enlightment is appreciated. TIA.

– greg willits

On 10/7/07, Greg W. [email protected] wrote:

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 Oct 6, 2007, at 8:27 PM, Greg W. wrote:

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 :

That operator is called “ternary” because it needs 3 operands
(addition is a binary operand, the unary minus acts on a single
operand).

Ok, fine, so I can write something like this:

$debug ? $devLog.info(“bla bla bla”) :

Write it like this instead:

$devLog.info(“bla bla bla”) if $debug

– fxn

You might enjoy the “short-circuiting” operators instead:

condition && ifitstruedothis()
or
condition || ifitsfalsedothis()

these are like C. Cheers, -r.

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.

Hope this helps

Indeed. Thanks much.

– gw

Jay L. wrote:

On Sun, 7 Oct 2007 03:44:20 +0900, Greg W. wrote:

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 :slight_smile:

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 W. wrote:

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):

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:

puts “First name: #{first_name}” unless first_name.nil?

where the “unless” is more of a guard statement.

Hi –

On Sun, 7 Oct 2007, Greg W. wrote:

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 :slight_smile: 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

On Sun, 7 Oct 2007 04:28:34 +0900, Greg W. 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”?

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.

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 L. 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 :slight_smile:

Heh. True. :slight_smile:

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.

Thanks everyone. I look forward to more chats :slight_smile:

– gw

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 J. 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…

Jay L. wrote:

On Sun, 7 Oct 2007 10:24:35 +0900, John J. 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…)