From: Intransition Date: 2012-03-19T02:52:01+09:00 Subject: Re: why no decreasing enumerations? ------=_Part_480_20335283.1332093118479 Content-Type: multipart/alternative; boundary="----=_Part_481_23218185.1332093118479" ------=_Part_481_23218185.1332093118479 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. > 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. ------=_Part_481_23218185.1332093118479 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

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.


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.

------=_Part_481_23218185.1332093118479-- ------=_Part_480_20335283.1332093118479--