Bug #1165

Range.eql? and Range.== bug with subclasses

Added by marcandre (Marc-Andre Lafortune) over 11 years ago. Updated over 9 years ago.

Target version:
ruby -v:
ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-darwin9.6.0]


Contrary to the documentation (and to what I would expect):

class TrivialRangeSubclass < Range
end,1) ==,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

* range.c (range_eql, range_eq): fixed equality to work for
  subclasses of Range.

* test/ruby/test_range.rb: add assertions for above.

Thank you!


ruby-changes.patch (1.16 KB) ruby-changes.patch marcandre (Marc-Andre Lafortune), 02/17/2009 05:10 AM

Updated by marcandre (Marc-Andre Lafortune) about 11 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 yugui (Yuki Sonoda) about 11 years ago

  • Status changed from Open to Closed
  • Assignee set to yugui (Yuki Sonoda)
  • Target version changed from 2.0.0 to 1.9.2




Updated by runpaint (Run Paint Run Run) about 11 years ago

Was this meant to be closed? It doesn't appear to have been resolved.


Updated by ujihisa (Tatsuhiro Ujihisa) about 11 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.


Updated by marcandre (Marc-Andre Lafortune) about 11 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

Also available in: Atom PDF