From: "trans.  (T. Onoma)" <transami@...>
Date: 2004-10-14T06:50:08+09:00
Subject: Re: Ruby Directions (was Re: quality of error messages)

On Wednesday 13 October 2004 05:06 pm, Austin Ziegler wrote:
| On Thu, 14 Oct 2004 05:00:46 +0900, trans.  (T. Onoma)
|
| <transami@runbox.com> wrote:
| > On Wednesday 13 October 2004 03:46 pm, Charles Hixson wrote:
| > | I think the built-in parts of the language need to work together
| > | smoothly, and the current range does that properly and efficiently.
| >
| > But in fact, much of the discussion has been about how Range behavior is
| > NOT "proper" nor efficient.
|
| And I, for one, disagree with people who say that Range behaviour is wrong.

"wrong" is relative. Obviously Range is very usable _as is_. That doesn't mean 
there is nothing wrong with it.

  - #member? is *very* slow
  - #member? can cause infinite loop
  - #include? != #member? (so not exactly Enumerable)
  - can't use case statement as membership check, one inclusion check
  - #irregular optimization of Numerics, so it doesn't always
    behave consistently (try creating an even integer class)
  - Does not offer exclude_begin
  
This is off the top of my head. I'm sure we've covered a few others, too.

| [snip]
|
| I find absolutely nothing surprising about the current behaviour of
| ranges: they act both continuous and discrete, depending on how you
| use them. There are a couple of issues: it is not possible to do:
|
|     (0..5).step(0.25)
|     (0...5).step(0.25)
|
| This would make it possible to deal with non-integer discrete ranges.
| Is *that* worth doing, perhaps? I think so.

In fact, my modified Range class does this handedly using #each, as well as 
dividing the range up into any equal divisions, also using #each --so all 
Enumerable methods work with it, as well as #to_a.

| It doesn't, however, mean that Ranges are fundamentally broken.

No one ever said that. We've simply been exploring how Range might be made 
more consitant, useful and efficient.

T.