From: Rick DeNatale <rick.denatale@...>
Date: 2008-03-31T01:30:47+09:00
Subject: Re: Recent changes in Range#step behavior

On Wed, Mar 26, 2008 at 5:38 PM, Dave Thomas <dave@pragprog.com> wrote:

>  By definition, ranges are defined for all objects other than a few
>  built-in ones to use succ() and comparisons. Thus they are by
>  definition a representation of a set of values.

There's been at least one rather extended thread on Ruby talk about
the requirements of range elements.
I think these two quoted sentences can be read to imply that range
endpoints MUST implement both succ() and comparisons.  I think that
this interpretation is overspecifying, and rules out useful ranges
such as

(1.5..3.0)

Such a range is quite useable as long as you restrict yourself from
using methods like each or to_a, whose implementations rely directly
or indirectly on succ.

A similar situation is that you can use

%w(one two three).sort

but not

[:one, :two, :three].sort

or at least in Ruby 1.8 where symbols aren't comparable. Of course
there are other non-sortable arrays in 1.9, for example ["one", 2,
3.0].

And I don't think we'd want to disallow, say,  heterogeneous arrays in general.

I see this as an interesting aspect of duck typing in that whether or
not a given object is a duck depends solely on exactly what quacking
it's required to do in a particular usage, and that whether or not it
can actually quack in a particular way might depend on its state and
not just its class.

> The elements in 1..3
>  are the integers 1, 2, and 3. The float 1.5 is not a member of this
>  list, so member? should return false in this case. I strongly advocate
>  fixing the current behavior so that the method name and the method
>  behavior are more aligned. That way cover? can do its thing and
>  member? can do its.

In general I agree, although one has to consider cases like this:

(1.5..3.0).member?(2.3)

I think you want to leave cases in which the end points don't quack
with the right methods (at least succ here) as undefined and let them
throw method_missing.

Exactly how much of this should be in the documentation is a question.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/