From: Robert Klemme <bob.news@...>
Date: 2005-07-14T05:30:53+09:00
Subject: Re: NoMethodError in Range#include?

Levin Alexander <levin@grundeis.net> wrote:
> Robert Klemme <bob.news@gmx.net> wrote:
>
>>>> An easy way around it is to use ('a'..'z').entries.include?(1)
>>>> instead
>>>
>>> That does not work when Range#start is a Float (and it builds an
>>> additional Array)
>>
>> Also, there are several equally valid interpretations of
>> Range#include?:
>
> (a)
>>  - True, if the range while iterating yields the specific value (std
>> definition from Enumerable)
>
> (b)
>>  - True, if low <= x <= high
>
> (c)
>>  - True, if low < x <= high
>
> Interesting.  I would lean towards (b) (which I believe is the current
> implementation if exclude_end? is false).

In that case the inclusion of Enumerable becomes questionable.

> (a) is not really practical because Range is not always Enumerable and
> this also conflicts with my mental model of a "Range"

Right:

>> (1.5 .. 3.4).to_a
TypeError: cannot iterate from Float
        from (irb):14:in `each'
        from (irb):14:in `to_a'
        from (irb):14

We have the weired situation that a Range where left and right are 
enumerable (integers, strings) the inclusion of Enumerable is ok and for non 
enumerable types (Float) it's not.  That's a bit weired situation IMHO, at 
least not exactly good design.

>> So maybe Range#include? is not that useful after all...  Or we should
>> leave the std definition from Enumerable in place and introduce
>> Range#contains? or Range#covers? to deal with the more range specific
>> interpretations.
>
> A little more context on what I was trying to do:
>
> I'm writing a class to filter bytestreams according to various
> parameters=

Huh?  Sent too early?  I'm missing the rest of the sentence here.

Kind regards

    robert