Best uses for true, false, and nil objects

The simplest Ruby objects are true and false. In general, if true and false will meet your needs, you should use them. true and false are the easiest objects to understand.

There are a few cases where you will want to return true or false and not other objects. Most Ruby methods ending with ? should return true or false. In general, the Ruby core methods use the following approach:

1.kind_of?(Integer)
# => true

Similarly, equality and inequality operator methods should return true or false:

1 > 2
# => false
1 == 1
# => true

A basic principle when writing Ruby is to use true or false whenever they will meet your needs, and only reach for more complex objects in other cases.

The nil object is conceptually more complex than either true or false. As a concept, nil represents the absence of information. nil should be used whenever there is no information available, or when something requested cannot be found. Ruby's core classes use nil extensively to convey the absence of information:

[].first
# => nil
{1=>2}[3]
# => nil

While true is the opposite of false and false is the opposite of true, nil is sort of the opposite of everything not true or false. This isn't literally true in Ruby, because NilClass#! returns true and BasicObject#! returns false:

!nil
# => true
!1
# => false

However, nil being the opposite of everything not true or false is true conceptually. In general, if you have a Ruby method that returns true in a successful case, it should return false in the unsuccessful case. If you have a Ruby method that returns an object that is not true or false in a successful case, it should return nil in the unsuccessful case (or raise an exception, but that's a discussion for Chapter 5, Handling Errors).

Ruby's core classes also use nil as a signal that a method that modifies the receiver did not make a modification:

"a".gsub!('b', '')
# => nil
[2, 4, 6].select!(&:even?)# => nil
["a", "b", "c"].reject!(&:empty?)# => nil

The reason for this behavior is optimization, so if you only want to run code if the method modified the object, you can use a conditional:

string = "..."
if string.gsub!('a', 'b')
  # string was modified
end

The trade-off here is that you can no longer use these methods in method chaining, so the following code doesn't work:

string.
  gsub!('a', 'b').
  downcase!

Because gsub! can return nil, if the string doesn't contain "a", then it calls nil.downcase!, which raises a NoMethodError exception. So, Ruby chooses a trade-off that allows higher performance but sacrifices the ability to safely method chain. If you want to safely method chain, you need to use methods that return new objects, which are going to be slower as they allocate additional objects that need to be garbage collected. When you design your own methods, you'll also have to make similar decisions, which you will learn more about in Chapter 4, Methods and Their Arguments.

One of the issues you should be aware of when using nil and false in Ruby is that you cannot use the simple approach of using the ||= operator for memoization. In most cases, if you can cache the result of an expression, you can use the following approach:

@cached_value ||= some_expression
# or
cache[:key] ||= some_expression

This works for most Ruby objects because the default value of @cached_value will be nil, and as long as some_expression returns a value that is not nil or false, it will only be called once. However, if some_expression returns a nil or false value, it will continue to be called until it returns a value that is not nil or false, which is unlikely to be the intended behavior. When you want to cache an expression that may return nil or false as a valid value, you need to use a different implementation approach.

If you are using a single instance variable for the cached value, it is simplest to switch to using defined?, although it does result in more verbose code:

if defined?(@cached_value)
  @cached_value
else
  @cached_value = some_expression
end

If you are using a hash to store multiple cached values, it is simplest to switch to using fetch with a block:

  cache.fetch(:key){cache[:key] = some_expression}

One advantage of using true, false, and nil compared to most other objects in Ruby is that they are three of the immediate object types. Immediate objects in Ruby are objects that do not require memory allocation to create and memory indirection to access, and as such they are generally faster than non-immediate objects.

In this section, you learned about the simplest objects, true, false, and nil. In the next section, you'll learn about how best to use each of Ruby's numeric types.