A few years ago, I was reviewing a PR for a junior dev who was building a caching layer for a pricing engine. He had a Hash where the keys were product IDs, and he was trying to retrieve a cached price using a variable he thought was a matching ID. The logic looked perfect: if cache[id]. However, in production, the cache was missing hits constantly. It turned out he was occasionally passing the ID as a Float (e.g., 101.0) while the keys in the Hash were Integers (101). He told me, "But I checked it with == and it returned true!" He was right—101 == 101.0 is true in Ruby—but the Hash didn't care about ==. It used something else entirely.

Value Equality and the Flexibility of ==

When you use ==, you're generally asking, "Do these two objects represent the same value?" In Ruby, == is a method that can be overridden by almost any class to define what "equality" means for that specific type of object. This is why it's so flexible. For example, if you compare two different string objects that happen to contain the same characters, == returns true because the content is the same.

str1 = "ruby"
str2 = "ruby"
puts str1 == str2 # => true

I usually tell people to treat == as the "intuitive" check. It's the one you'll use 95% of the time. However, because it's so easily overridden, it can sometimes be too permissive, which leads us to the next level of strictness.

The Strictness of eql? and the Hash Connection

The eql? method is similar to ==, but it's designed to be more rigorous. Its primary purpose in the Ruby ecosystem is to serve as the basis for Hash key lookups. For most classes, eql? behaves exactly like ==, but for numeric types, it's a different story. eql? requires that the objects not only have the same value but also be of the same class.

1 == 1.0    # => true
1.eql?(1.0)  # => false

This explains the bug from my anecdote. When you put a key into a Hash, Ruby doesn't use == to find it later; it uses eql? (and the object's hash method). If you use an Integer as a key, you cannot retrieve that value using a Float, even if they are mathematically equivalent. If you're building a system where types might be mixed—like data coming from a JSON API where numbers might arrive as floats—be very careful about which equality method is being invoked under the hood.

Identity and the Absolute Certainty of equal?

Finally, we have equal?. This is the strictest check of all. It doesn't care about values or classes; it only cares about identity. It asks: "Are these two variables pointing to the exact same object in memory?"

a = "hello"
b = "hello"
c = a

puts a.equal?(b) # => false (different objects, same value)
puts a.equal?(c) # => true  (exact same object)

You won't use equal? often in daily business logic, but it's an indispensable tool for debugging. If you suspect that a method is mutating an object instead of returning a new copy, equal? is how you prove it. It essentially compares the object_id of the two instances. If the IDs match, they are the same piece of memory, period.

📋 Practical Task

The Strict Identity and Value Validator

You are tasked with writing a diagnostic method for a library that handles sensitive data. You need to create a method called compare_objects(obj1, obj2) that returns a specific string describing the relationship between two inputs.

The method should follow these rules:

• Return "Identical" if the objects are the exact same instance in memory (using equal?).
• Return "Equivalent" if the objects have the same value but are different instances or different types (using ==).
• Return "Different" if neither of the above is true.

Test your method with these cases:

# Case 1: Identical
x = [1, 2, 3]
y = x
compare_objects(x, y) # Should return "Identical"

# Case 2: Equivalent
a = "Ruby"
b = "Ruby"
compare_objects(a, b) # Should return "Equivalent"

# Case 3: Equivalent (but different types)
compare_objects(10, 10.0) # Should return "Equivalent"

# Case 4: Different
compare_objects("Ruby", "Python") # Should return "Different"