Nil explained
It’s already been a couple of weeks at Flatiron School’s coding bootcamp and according to its traditions, every cohort should choose its name. My cohort was not exception and by the end of the first module, we exercised our democracy rights and voted to choose representation of our cohort name. As in every free and democratic places, we started to see the “Rule of the majority” in action and winning number of voters were given power to name the cohort.
Finally, the name was chosen to be “Cohort has Nil name”. I am not going to be subjective about the name and will not try to attest my opinion about it however, as an accountable member of a democratic society, I will take my civic duty and try to explain the most important part of our cohort name — Nil. Since majority of the cohort chose this name, it is our responsibility to know what exactly it is, what it’s value is, how to exercise it and how to implement it in our every day Ruby life.
As with nearly everything in Ruby, nil is an object too. It is a special value, used to express the absence of value or something that represents “nothing”. How can we prove this to ourselves?
Let’s create an array and then see what an unassigned index on an array returns.
We can clearly see that index 5 returns nothing in this example, therefore we get nil as a returning value.
As I mentioned before, nil is an object and in fact, it is a singleton instance of NilClass, same goes for the true and false Booleans in Ruby. They are singleton instances of TrueClass and FalseClass.
This means that just like any other object in ruby, nil has its own set of methods. This is very useful for not getting inconvenient errors, if somehow the returning value of your code ends up being a nil value. These methods give us an opportunity to transform an absence of value into an array, a string, or even a hash and an integer.
Therefore, we can call all these methods on nil.
We can see that to_[something] methods return an empty array, hash, string, or Zero(0) for numbers. This evaluation proves again that nil is something that represents empty value or “nothing”, however it can still represent something, as Sandi Matz mentions in her talk “Nothing is Something”.
In addition, the nil? Method has been moved to the very top of the object class, meaning that rather than returning NoMethodError, you can call this method on any object and it will give us a resulting return. For example:
This test leads me to a very interesting and important point about nil. Every value in Ruby is true, except false and nil. Nil behaves like a false and nil is true only when it equals to itself (nil == nil). It’s logical since it represents an absence of a value.
Therefore, it is up to us, programmers, as to how we are going to improvise nil in our code. Can we use it for comparison? Or, do we want to turn it into an empty something? Ruby is great because it can really represent Nothing as Something. Or, turn Nothing into Something.
In addition, I want to quickly talk about very common mistake we can make with nil, while using enumerable. As we know, puts and print always return nil. So using them with enumerables will result in returning numbers as nils.
For example:
To avoid this mistake, we just need to remove in this case puts from the block.
Finally, there is one more interesting fact about nil. Since nil is an object, we can assume that is has an object id too. Let’s test:
As we can see, nil has the object_id of 8(in the 64-bit Ruby) and 4(in the 32-bit Ruby). This number is hardcoded in Ruby. Object_id for nil never changes. The reason behind it is that it is a singleton instance of it’s class, as I mentioned above. Same goes for false and true. Their object_ids are 0 and 2 respectively. Object_id numbers 1 and 3 are Fixnum values.
At last, even though some of us thought that our cohort name did not hold any values, or that meant to represent nothing, it turns out that in fact nil can be used in various ways and transform/convert our return values into something else.
