In ruby, comparing hashes, strings and objects is a complicated topic. Should you use equal?, eql? or ==? There is plenty of help on this topic, but in this post, we will focus on the interesting behavior of the == operator and how you can make it behave as you need it for your use case.
When comparing Hashes in Ruby, the == operator compares the content of a hash recursively.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
my_hash = {
:sub_hash => {
:value => 42
}
}
my_second_hash = {
:sub_hash => {
:value => 42
}
}
my_third_hash = {
:sub_hash => {
:value => 21
}
}
puts "my_hash == my_second_hash? #{my_hash == my_second_hash}"
puts "my_hash == my_third_hash? #{my_hash == my_third_hash}"
|
1 2 |
my_hash == my_second_hash? true my_hash == my_third_hash? false |
Unfortunately, when comparing objects of arbitrary classes, the default operator only compares the object identity.
1 2 3 4 5 6 7 8 9 10 |
class MyClass def initialize(value) @value = value end end my_object = MyClass.new(42) my_second_object = MyClass.new(42) puts "my_object == my_second_object? #{my_object == my_second_object}" |
1 |
my_object == my_second_object? false
|
If you want to do a deep comparison of objects of your class, you need to implement your own operator == by overriding the existing operator.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
class MyClass attr_reader :value def initialize(value) @value = value end def ==(other) other.respond_to?("value") && value == other.value end end my_object = MyClass.new(42) my_second_object = MyClass.new(42) puts "my_object == my_second_object? #{my_object == my_second_object}" |
1 |
my_object == my_second_object? true
|
That was easy. But imagine this was a bigger class and someone else needed to add a property, not being aware of the existence of this operator and some other code depending on it to ensure no public member of the object changed. How can you ensure such a change doesn’t sneak in unnoticed?
I stumbled across the following solution when implementing an operator == for a class in the BOSH code together with my colleague Max.
As BOSH code is written in TDD – and your code should be as well – writing a test that breaks with a change as the one described above should ensure the operator to keep working. But how can such a test look like?
Consider the following change to our code above:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
class MyClass attr_reader :value attr_reader :value_new def initialize(value) @value = value @value_new = value end def ==(other) other.respond_to?("value") && value == other.value end end my_object = MyClass.new(42) my_second_object = MyClass.new(42) puts "my_object == my_second_object? #{my_object == my_second_object}" |
To detect the variable @value_new has been added using rspec can be done with a test like the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
require './object_compare_op' describe :MyClass do describe 'operator ==' do context 'when instance variables are modified' do let :obj do MyClass.new(42) end let :other_obj do MyClass.new(42) end all_members = MyClass.new(0).instance_variables.map { |var| var.to_s.tr('@', '') } all_members.each do |member| it "returns false when #{member} is modified" do eval <<-END_EVAL class MyClass def modify_#{member} @#{member} = 'foo' end end END_EVAL obj.send("modify_#{member}") expect(obj == other_obj).to( equal(false), "Modification of #{member} not detected by == operator.", ) end end end end end |
The variable @value_new only has an attribute reader, so we cannot simply assign a new value. But this doesn’t stop you from changing the value. Not in Ruby. Using the eval in the test, we add a method for all existing instance variables of MyClass (one in each iteration) that modifies the member.
Afterwards, the newly added method is called to change the value of the member and the expect checks if the operator detects the modification. And – for our code above – will fail. Hence, whenever someone adds a new member to MyClass, he will be reminded to also it to the operator == by this test. Even if the code of test itself might not be as speaking, the output of the failing test is:
Modification of value_new not detected by == operator.
In some situations you may want to exclude a member from this check as it is just internal or not important to the equality of two objects. To enable this, we added an exclude list for private members to the test. This adds a bit of complexity to adding new members to the class as the test will bother you and you also have to add the member to the exclude list, but it improves the safety of your operator ==.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
require './object_compare_op' describe :MyClass do describe 'operator ==' do context 'when instance variables are modified' do let :obj do MyClass.new(42) end let :other_obj do MyClass.new(42) end all_members = MyClass.new(0).instance_variables.map { |var| var.to_s.tr('@', '') } private_members = %w[value_new] public_members = all_members - private_members public_members.each do |member| it "returns false when #{member} is modified" do eval <<-END_EVAL class MyClass def modify_#{member} @#{member} = 'foo' end end END_EVAL obj.send("modify_#{member}") expect(obj == other_obj).to( equal(false), "Modification of #{member} not detected by == operator.", ) end end end end end |
With this kind of test, you can easily implement comparison operators for your classes that check for object equality rather than identity and ensure you do not forget to add new members of the class also to the comparison.
You can take a look at productive code in the BOSH code base here. As you may see it’s not much different to what I presented here – it’s a universal approach to solve the problem.
Categorised in: Uncategorized
This post was written by Manuel Dewald
