By looking at the definition of the Range class http://www.ruby-doc.org/core/classes/Range.html
- please note that x..y is the same as Range.new(x,y) -
one can conclude that Ranges are constructed using <=> and .succ.
While it is true that "Z".succ == "AA" it is also true that "Z" <=> "AA" is
implying "Z">"AA" and
therefore Range("Z".."AA") seems correctly empty.
What might come as a surprise is that you have found a ruby object that is
greater than its successor but that depends on the kind of *order* we are
dealing with. This oddness comes from String, not from Range though. By
carefully looking at the definition of succ and <=> in String one can ask
oneself if constructing Ranges from Strings is very useful in all contexts
because <=> and succ do not seem to be desinged for the same view of the
String domain.
BTW what do you think ("AA".."Z").to_a delivers (should be infinite by the
same reasoning, should it not?).
It seems therefore that some classes are not made to be used for Ranges
although they are Compareable and Enumerable which is not very reassuring. I
guess you just opened Pandorra's can
Maybe that is because it was not clear that "<=>" and "succ" depend on each
other by the design of the language and as they are used for other things
"<=>" for Compareable one could argue that we have too closely coupled
bahvior here. And while one could argue so, I do! Different methods should
be used to define Range (e.g. range_smaller?, range_next).
Cheers
Robert
···
On 5/28/06, Kevin Olbrich <kevin.olbrich@gmail.com> wrote:
I think I may have stumbled upon a minor bug in ranges.
on my system,
("Z".."AA").map returns
while
"Z".succ returns "AA"
"Z".upto("AA") also returns
ruby 1.8.4 (2005-12-24) [i686-darwin8.6.1]
Is this a real bug, or am I expecting behavior that really shouldn't be
there?
pointer.
It seems to me, and that is eventually a clear statement from my side ;),
that this needs more discussion.
Please kindly try to forget what I have written sofar - because of the noise
- and evaluate the following statement.
It is bad that Range builds its behavior upon <=> and succ, because <=> and
succ are not designed (not always at least) to work together for that
purpose.
I conclude from Matz' post that this confusion could be clarified by
redesigning Range to be build on a contract that does not interfere with
other contracts. Changing the paradigme.
I am well aware that such a redesign might have more impacts ( for logical
compatibility with the Enumerable mixin f.i.) than one might think of at
first sight but the OP's confusion and the previous discussion make it quite
clear to me...
Thanks for listinening.
Robert
···
On 5/29/06, Ryan Leavengood <leavengood@gmail.com> wrote:
Just an FYI, this general topic of ranges and strings has been
discussed extensively in the recent past: