I became intrigued about object ids when I was researching into the .equal? operator in my earlier post on Ruby equalities, and also when I was wading through Ruby Koans’ about_object.rb.

And so, here’s my summary on the questions I had, and the answers that my research yielded:
1) What is an object id?
2) Why is true.object_id != 1?
3) Which objects have fixed object_ids, and what are the practical implications?

1) What is an object id?
An object id is a unique identifier for an object, much like a fingerprint. All objects have an object id. In Ruby, the method .object_id returns an object’s unique identifier, which is presented by a number or a string of numbers.

2) Why is true.object_id != 1?
Given that true and false are a fundamental part of most programming languages, I expected the object id for true to be 1, and the object id for false to be 0.

So it surprised me to find that while false.object_id == 0, true.object_id == 2, and nil.object_id == 4. Why do true and nil have such strange object ids?

The reason for that is that the other, perhaps more obvious numbers (like 1 and 2) are taken up by integers due to the pattern for Fixnum (integer) object ids.

As was tested in Ruby Koans’ about_object.rb, in Ruby, the object ids for integers (i) follow the pattern: i * 2 +1 such that:

This pattern also holds true for negative integers:

3) Which objects have fixed object_ids, and what are the practical implications?
As part of my earlier post on Ruby equalities, I tinkered around a lot with .object_id in irb, researching the application of the .equal? operator.

Overall, objects seem to fall into 3 categories:
i) those with fixed object ids
ii) those with temporarily fixed object ids
iii) those with changing object ids

Objects with Fixed object ids:
1) Fixnum
As mentioned above, integers have fixed object ids.

2) Symbols
Once created, symbols have immutable object ids, which will remain constant, even if the values have been reassigned.

For example:

In all cases, the object_id of the symbol name is identical

Objects with temporarily fixed object ids:
1) Variables
Once created, variables will have the same object id each time it is called, unless the variable has been reassigned, in which case, the variable object id will change. While the variable retains its assigned value, its object id is temporarily constant:

If a variable is assigned to a Fixnum, the variable will take on that Fixnum’s object id:

This will also apply in the case where a variable is assigned to a symbol:

2) Arrays
Like variables, arrays have a temporarily fixed object id while the contents of the array have not changed:

3) Hashes
Like variables and arrays, hashes have a temporarily fixed object id while the contents of the array have not changed:

Objects with changing object ids:
1) Floats
Floats have new and different object ids, each time they are called:

2) Strings
Strings have new and different object ids, each time they are called:

3) Instances of an object
A new object, once created, behave very much like variables – they have the same object id each time they are called, as long as they have not been modified. Each iteration of the object will result in a temporarily fixed object id:

However, each instance of an object, including clones of another object, have their own unique object id:

Implications / applications:
As far as I know, the primary (most common) application of the above object id properties, are in the usage of symbols rather than strings for naming things or representing data.

Given that symbols have an immutable object id once they are created, whereas strings have a different and individual object id each time they are called, symbols take up less space in the computer’s memory. Hence, we should use symbols instead of strings as hash keys, or attributes – because if the hash key or attribute will be called over and over again, using symbols will significantly increase the performance of the program.

I found Robert Sosinki’s tutorial on Symbols vs. Strings particularly illuminating.