I support this proposal. In a basic programming lecture, I just recently told students how to compare (<, <=, and so on) numbers and strings, and then mentioned that it would work the same way for Arrays. But then when I wanted to show this, it didn't work.
I was quite surprised, because I had sorted Arrays many times before. Then I vaguely remembered: Ah, yes, there's a <=> operator for Arrays, but if you want to use <, <=, ..., you have to include Comparable. It's the way it currently is, but it's totally unclear why, and it's difficult to remember.
Ruby Facets provides a Tuple class, which is an immutable Array that is also Comparable. I believe I may have suggested Ruby provide such a class in the past. If Array can not be Comparable for some reason, perhaps this is a reasonable alternative.
Ruby Facets provides a Tuple class, which is an immutable Array that
is also Comparable. I believe I may have suggested Ruby provide such a
class in the past. If Array can not be Comparable for some reason,
perhaps this is a reasonable alternative.
I remember that in ruby-core long ago matz explained that array don't include comparable because they could contain elements that are not comparable.
I dont see this as problem as this is violated in most classes when comparing field that can be nil.
Since arrays are not always compatible, I don't want to give wrong implication by making arrays comparable.
Adding <=> was a realistic compromise for me to allow array sorting.