Closed khezam closed 1 year ago
Thank you @khezam for your contribution ❤️
I might agree in principle on the ==
changes, but I'm concerned about unexpected changes for all existing clients.
This PR also lacks testing, but don't worry about test/spec live
just yet, at this point they are expected to fail, we'll run them if we decide to proceed.
cc @snatchblock, what do you think of these changes?
My pleasure @ecoologic :)
I see your concerns about unexpected changes for all existing clients and the lack of testing. I was/am expecting the existing tests would catch any unexpected behaviors since this PR only cleans up the current logic of ==
.
I'm happy to add a test coverage if needed.
Let me know :)
Hey @ecoologic, any update on this PR?
Hi @snatchblock,
I definitely can add test cases, but this PR does not need test cases because it does not add/remove from the existing logic, it's only rearranging the existing logic. The test cases already exist here, and if I add test cases, they'll be exactly the same.
The two methods below are exactly the same but the only difference is that the top one is easy to read.
def ==(other)
return false unless other
return true if other.object_id == object_id
return other.id && (other.id == id) if other.is_a?(Data)
return id == other if other.is_a?(Integer)
warn "Trying to compare #{other.class} to a Resource
from #{caller.first}"
end
def ==(other)
return true if other.object_id == object_id
if other && !(other.is_a?(Data) || other.is_a?(Integer))
warn "Trying to compare #{other.class} to a Resource from #{caller.first}"
end
if other.is_a?(Data)
other.id && other.id == id
elsif other.is_a?(Integer)
id == other
else
false
end
end
Let me know if I'm missing anything and I'm happy to add test cases accordingly.
The logic of
==(other)
method was a bit confusing so I tried to clean it up to make it easy to read. I also movednew_from_response
class method ofData
intoclass << self
for consistency.Let me know if there is anything I can change and make it better.