Range.eql? and Range.== bug with subclasses
Contrary to the documentation (and to what I would expect):
class TrivialRangeSubclass < Range
TrivialRangeSubclass.new(0,1) == Range.new(0,1) # ==> false
This bug is present in the current versions of ruby 1.8.7 and 1.9.1. As a matter of curiosity, I checked both JRuby (1.1.6) and rubinius (0.10.0) and they both return true (as they should).
Although I'm not familiar with the source code, it seams like a simple change, so I've included a patch for the 1.9.1 version. I hope I did things correctly! Changelog could read like:
Mon Feb 16 14:35:35 2009 Marc-Andre Lafortune email@example.com
* range.c (range_eql, range_eq): fixed equality to work for subclasses of Range. * test/ruby/test_range.rb: add assertions for above.
Updated by marcandre (Marc-Andre Lafortune) over 10 years ago
This change was made to bring Range#== and #eql? in line with the same methods for Array, Hash, String or Time in regards to subclasses. They should follow the same pattern unless there is a crucial reason not to, and in that case it must be clearly documented.
Additionally, note that String#==, for example, has the same explicit requirement in the documentation that the compared object "is a" String for == to return true. Other instances in the documentation also concur that "is a" should be understood as "is_a?", e.g. String#=~.
Updated by ujihisa (Tatsuhiro Ujihisa) about 10 years ago
Current documentations don't mention about a subclass of Range.
Actually the Japanese one was fixed not to mention about a subclass of Range in May. http://redmine.ruby-lang.org/issues/show/1446
Updated by marcandre (Marc-Andre Lafortune) about 10 years ago
Thanks Ujihisa for these links.
The fact that the doc doesn't mention the behavior for subclasses (which is true as well for String, Array, Hash, Time) doesn't change what the best behavior should be.
Could this ticket be set back to "Open", since no change appears to have taken place and no justification for the current behavior was given? Thanks