I think you misunderstand the purpose of ranges. They aren't meant to be
ordered lists but rather some kind of abstract interval (like in
mathematics). You can check if a specific object is in the range, but
you may not even be able to enumerate all the elements of the range.
For example, try
(1.0 .. 5.0).each {|el| puts el}
This raises a TypeError: "can't iterate from Float"
Of course, you *can* iterate over some ranges (if the endpoints have a
succ method). But then the elements will simply be put out in the most
obvious way: from low to high. The range itself doesn't imply a certain
order.
If you actually want to count up/down from some integer to another, you
should use an appropriate data structure like an enumerator:
a, b = rand(20), rand(20)
list = if a <= b
a.upto b
else
a.downto b
end
Ranges server dual purpose, so I don't think that's the reason. I think
there is no other reason then no one has implemented support for descending
ranges. It does require a new method #pred (opposite of #succ) though.
Of course, then again matz can have some peculiar objections to things some
times, so I could be wrong.
···
On Sunday, March 18, 2012 1:21:21 PM UTC-4, Jan E. wrote:
Hi,
I think you misunderstand the purpose of ranges. They aren't meant to be
ordered lists but rather some kind of abstract interval (like in
mathematics). You can check if a specific object is in the range, but
you may not even be able to enumerate all the elements of the range.
Shouldn't that be #prec (precede/succeed, or precessive/successive)
rather than #pred?
···
On Mon, Mar 19, 2012 at 02:52:01AM +0900, Intransition wrote:
On Sunday, March 18, 2012 1:21:21 PM UTC-4, Jan E. wrote:
>
> I think you misunderstand the purpose of ranges. They aren't meant to be
> ordered lists but rather some kind of abstract interval (like in
> mathematics). You can check if a specific object is in the range, but
> you may not even be able to enumerate all the elements of the range.
Ranges server dual purpose, so I don't think that's the reason. I think
there is no other reason then no one has implemented support for descending
ranges. It does require a new method #pred (opposite of #succ) though.
To me, that implies that there is only one successor, but I don't know
what the person who named the method thinks about it.
···
On Mon, Mar 19, 2012 at 12:16:40PM +0900, Intransition wrote:
On Sunday, March 18, 2012 5:15:51 PM UTC-4, Chad Perrin wrote:
>
> Shouldn't that be #prec (precede/succeed, or precessive/successive)
> rather than #pred?
>
I always thought of it as "predecessor/successor".