So everything I have thus far read and heard about the Ruby unless
keyword led me to believe that it is just another word for if not. This
is not true.
this code fails and complains that it expects an end to be where elsif
is
however
if not 1 + 1 == 2
puts “a”
elsif 1 + 1 == 5
puts “b”
else
puts “c”
end
works as expected. This took me quite a while to figure out as everyone
has always led me to believe that unless is just the cool kids way of
saying if not in ruby.
So I guess my question is, are there any other unexpected behaviors of
unless that I should know about? I think I might just start using if not
and ignoring unless, I actually end up having to translate it to if not
in my head anyway to read things clearly, and it doesn’t work with
elsif. Why does everyone rave about how unless is exactly like if not
but with clearer language, if this is not the case ?
‘elsif’ has to follow an ‘if’ NOT an ‘unless’. It doesn’t make sense to
follow unless with an if statement. What you want is ‘elsunless’, but
that doesn’t exist in Ruby so chained unless statements aren’t possible.
Some people even frown upon ‘unless/else’ which is legal Ruby.
elsif. Why does everyone rave about how unless is exactly like if not
but with clearer language, if this is not the case ?
Your usage of unless is extremely unclear.
Most people would advise you to change
unless x == 2
a
else
b
end
to
if x == 2
b
else
a
end
Furthermore, I do not understand what you want to achieve:
your “b” case seems useless to me.
Assuming 1 + 1 really would be 5, it could not be equal to 2
at the same time and you would get the “a” case, not “b”.
I think this is a technical misunderstanding. It’s true that “unless”
usually is the same as “if not”, but that does not mean you can
literally replace every “if not” with “unless”. It’s not a macro. The
Ruby parser treats “unless” as a keyword on its own with special rules
where it can occur and how those structures are evaluated.
So when you talk about “unexpected behaviour”, this is rather a problem
of you having the wrong expectations. Saying that one thing means the
same as another does usually not mean they’re actually interchangeable
on syntax level.
And you have to admit your first example really makes no sense. If this
was possible, Ruby would need some serious redesign.
Me too, usually. Sometimes it’s the case that, for example, you’ve
iterated through a large collection, performing actions on members and
whatever, and then at the end you only want to proceed if certain
conditions were met during iteration. Then, depending on how you
track the conditions, bail unless more_needs_to_be_done can be
appropriate. It always depends on the situation, and where you want
to trade off readability and maintainability (and, sometimes,
efficiency.)