Re: Recent changes in Range#step behavior

Hi Dave,

On Sun, Mar 23, 2008 at 4:26 PM, Dave Thomas <[e-mail]> wrote:
>  I can certainly fix that in the PickAxe, but I'm not sure what the
>  difference between a step and an increment is. Is it that an increment
>  is integral?

In some cases, there is no difference (e.g., for Fixnums, 4 succ's
equivalent to +4).
But in case of, say, Strings, iterating via #succ makes perfect sense,
but it's nonsensical to add 4 to the string.
In other case, Floats and Rationals, there is no sense in #succ, but
increments are perfectly valid and have some valid meaning.

So, here we are. The current ruby-doc defines #step in terms of #succ
and *iterations*. The description is not applicable to Floats and
Rationals, for example. For such cases, older MRI implementation
(patchlevel 111) happened to have special handling of Numerics, via
increments. The newer MRI implementation still has this special
handling for Numerics, but now converts the step argument to the
integer value, thus making the whole increment story confusing (why
would anyone like for (1.0..5.0).step(1.5) to actually increment by
just 1, and for
(1.0..5.0).step(0.5) to raise an exception *step can't be 0*?).

Also, what would happen if objecs in the range have both operations
(#succ and #+), which one would be selected? For fixnums, this doesn't
matter (both operations are equivalent), but for some other classes
this might be different.

Let's take the example of Xs from the Range ruby-doc. The #succ method
will be used for it. But, if we define the Xs as a subclass of
Numeric, then + will be used. The whole thing is just a bit to much
complicated.

Ideally, I'd probably just prohibit the use of #step in ranges where
iterations and #succ are not really defined, that would mean that
float or Rational ranges might not be used with #step. Well, after
all, (1.0..5.0).to_a is also not allowed. The change in the
implementation is simple (special handling for Numerics would be
deleted).

My second choise would be the old MRI behavior. If non-fixnum numerics
are allowed, then the increment should not be coerced to integer.

The current MRI behavior (1.9, 1.8 branch) is the least desirable, it
seems: it breaks compatibility with the old behavior, but the new
behavior is more confusing and leads to *silent* loss of precision
and/or confusing exceptions.

Thanks,
  --Vladimir