I = True and False in Ruby Is True

i = true and false in Ruby is true?

The operators && and and have different precedence, and = happens to be in between.

irb(main):006:0> i = true and false
=> false
irb(main):007:0> i
=> true
irb(main):008:0> i = true && false
=> false
irb(main):009:0> i
=> false
irb(main):010:0> 

The first is read as (i = true) and false, the second as i = (true && false).

Ruby: why does `puts true and false` return true?

Because puts binds stronger than and: your code is equal to

(puts true) and false
true
#=> nil

You can check operators precedence in docs.

To get what you could use &&, which has higher precedence than and:

puts true && false
false
#=> nil

Rails - map 1 to true in if statement

In Ruby everything is truthy except for nil and false. Thus both 0 and 1 are truthy - you will never reach the else part with this set up.

So in your case you want to check exactly for 0 or 1:

if isbookmarked == 1
  do something
elsif isbookmarked == 0
  do something
end

Is there a difference between `TRUE` and `true`?

The difference is that while true is a keyword in Ruby, TRUE is a constant:

true = 1
# => SyntaxError: Can't assign to true

TRUE = false
# => warning: already initialized constant TRUE
# => false

TRUE == true
# => false

boolean logic in ruby 'true and false == true'

Precedence. test = true and false means this:

(test = true) and false  

not this:

test = (true and false)

Use parentheses as above, or && instead of and, if you want the assignment to come last:

test = true && false

What evaluates to false in Ruby?

false and nil are the only ones:

http://www.ruby-doc.org/core-2.1.1/FalseClass.html

Rails provides present? which also includes empty strings and empty arrays: http://api.rubyonrails.org/classes/Object.html#method-i-present-3F

Can we overide true and false methods in Ruby?

true and false cannot be overridden because they are keywords, not methods. Their values are hard-coded and there's no way to re-assign a different value. (at least not from within Ruby)

Even when implementing a method with the same name, a literal true will still resolve to the built-in value.

---

What you can do is change the object, true is resolving to for interesting results: (this is just for fun, don't do this in actual code)

def true.inspect
  rand.to_s
end

true #=> 0.8499100640573652
true #=> 0.22279583303254913

However, the above example doesn't actually change the value of true in any way. Also, don't think of true as a method invocation returning a random float every time it is called. We are looking at the very same object:

a = true

a #=> 0.5813338288658235
a #=> 0.6447125630746154

What we did is change its representation by overriding inspect, which:

Returns a string containing a human-readable representation of obj.

We see those floats because IRB calls inspect in an attempt to print the last expression's result in a readable way.

If we set IRB's output mode to :to_s, our change is bypassed and we see true again:

IRB.CurrentContext.inspect_mode = :to_s

a    #=> true
true #=> true

Ruby (Rails 4.0.2): (1 == true) = false?

My understanding is that in the Ruby programming language, only nil and false are considered false, and EVERYTHING else is considered true

This is true.

However,

"Thus, 1 == true SHOULD return true."

is false.

Explanation: in Ruby everything except false/nil is considered true. However when testing for equality, like x == true you're actually not testing "is this value considered true" but "is this value equal to true".

And of course 1 isn't equal to true, 1 is a number and true is a boolean value. You can read a very good blog post about equality in Ruby at "Ruby Equality And Object Comparison".

If you really, really want to test it that way, you need to convert the expression like 1 to its boolean value, which you can do by double negating it. So !!1 # => true.

So, your examples will look like this:

!!1 == true # => true
!!0 == true # => true
!!"test" == true # => true
!!"" == true # => true

However I believe it isn't necessary in most cases.

When working with MSSQL you should let Active Record do all the conversions for you. Declare the field in a migration, with type boolean, and when you do your where search in the database, do it like this:

Model.where(['attribute = ?', true])
Model.where(:attribute=> true)

This way ActiveRecord will do all the work related to converting the type to a database compatible one for you.

---

Related Topics