Ruby Demystified: and vs. &&

#1

Post by angelirizarry » Fri, Mar 08, 2013, 8:57 PM UTC

Ruby Demystified: and vs. &&
blog.tinfoilsecurity.com

Re: Ruby Demystified: and vs. &&

#2

Post by klochner » Fri, Mar 08, 2013, 9:20 PM UTC

tldr: && has higher operator precedence than "and"

Significantly, "&&" > "=" > "and", which can lead to unintended results when refactoring "&&" --> "and"

Re: Ruby Demystified: and vs. &&

#3

Post by trebor » Fri, Mar 08, 2013, 9:21 PM UTC

klochner wrote: post #2

tldr: && has higher operator precedence than "and" Significantly, "&&" > "=" > "and", which can lead to unintended results when refactoring "&&" --> "and"

I.E.: why you should always use && instead of "and".

Re: Ruby Demystified: and vs. &&

#4

Post by danielweber » Fri, Mar 08, 2013, 9:23 PM UTC

Seeing "and" or "or" in Ruby code now leaps out at me with danger signs. I've decided it's just not worth it.

Re: Ruby Demystified: and vs. &&

#5

Post by caw » Fri, Mar 08, 2013, 9:25 PM UTC

danielweber wrote: post #4

Seeing "and" or "or" in Ruby code now leaps out at me with danger signs. I've decided it's just not worth it.

I've never actually seen "and" or "or" in Ruby code. I very frequently see it in Perl code.

Re: Ruby Demystified: and vs. &&

#6

Post by aston » Fri, Mar 08, 2013, 9:25 PM UTC

Not to start a language war, but this blog post demonstrates two things Python got right that Ruby got wrong.

First, in Python, there's only one way to express a boolean "and". The && operator is left out.

Second, this post demonstrates a danger of allowing assignment via '=' evaluate to an expression (granted with less weird precedence rules it wouldn't turn out as bad in this case).

Re: Ruby Demystified: and vs. &&

#7

Post by danso » Fri, Mar 08, 2013, 9:27 PM UTC

> When I first started learning Ruby, I was excited to discover that Ruby has the keywords and and or as boolean operators. I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable

     pry(main)> a = true && false
     
     pry(main)> a = true and false

Hmm...I dunno, I don't think the latter is necessarily easier to read than the former. The use of the symbols helps, for me at least, to delineate between value/variables and operators. Those symbols aren't pretty but their ugliness can serve a purpose.

I don't mind using them in SQL, but only because SQL is case-insensitive and I can stick to the style of making all syntax uppercase.

Re: Ruby Demystified: and vs. &&

#8

Post by pyre » Fri, Mar 08, 2013, 9:29 PM UTC

This is basically the author finding out something in Ruby that was copied from Perl. E.g. it allows one to do:

  $fh = open() or die("File did not open")

Instead of:

  $fh = open()
  die("File did not open") unless $fh

Re: Ruby Demystified: and vs. &&

#9

Post by eaurouge » Fri, Mar 08, 2013, 9:31 PM UTC

Makes for an interesting blog post, I guess. But precedence for "&&" and "||" in Ruby are similar to precedence for "&&" and "||" in C, Java and others, and they are similar to precedence rules for "and" and "or" in Python. Precedence rules for "and" and "or" in Ruby are an anomaly not just in the Ruby world but in many (most?) mainstream languages.

Re: Ruby Demystified: and vs. &&

#10

Post by amalag » Fri, Mar 08, 2013, 9:33 PM UTC

It was an interesting experiment while it lasted, but I don't think they make sense.