Dave,
Relative new Ruby user.
Welcome to Ruby!
Let's see if I've got this straight. Somebody
complained because('1'..'10').member?('2')
=> false
That is the tip of the iceberg, yes.
Good! The fact that Ruby will get incredibly clever
with strings and fabricate arbitrary sequences with
them is a charming trick, but they are arbitrary, and
it is a trick.
Why is this good? The Range '1'..'10' is a member of Enumerable.
As such, it has a finite number of elements and those elements can
enumerated (for lack of a better word) one at a time using #each. In
particular, this Range is enumerated as '1', '2', '3', '4', '5', '6',
'7', '8', '9', '10'. The method Enumerable#member?, will return true if
one of the enumerated elements is equal to the parameter. However, for
Ranges, the behavior of #member? is different. So different in fact
that for this Range, #mamber?('2') returns false. Many people see this
as a bad thing, not a good thing.
The fact that '1', '2', ... '9','10' is obvious
doesn't make it any less arbitrary.
However that sequence isn't arbitrary, all others are. A Range can
be defined on any object that supports #succ and #<=>. The #succ method
defines the *one and only* sequence that a Range cares about, in
relation to Enumerable. For strings, '1', '2', '3', '4', '5', '6', '7',
'8', '9', '10' is the *one and only* sequence that #succ generates, and
that is the sequence that Enumerable#member? would use if Range didn't
override the #member? method.
'1'..'100'
Is that supposed to be 1, 2, 3, ... 99, 100 or 1, 10,
11, 100? Ruby arbitrarily decided to interpret those
strings as base 10 integers.
No, it's supposed to be '1', '2', '3', ... '99', '100'. There is
nothing arbitrary about the sequence, and it's not a trick. It is the
sequence defined by String#succ. You are welcome to write your own
version of String#succ, but it won't change anything. Range#member?
will still ignore it.
'a.1'..'c.3'
Quite honestly, I have absolutely no idea how Ruby
would count that. Will I get 'a.1', 'a.2', 'a.3',
'b.1' ... or is it going to go all the way to 'a.9'
and then start over with 'b.1'?
Well, let's see:
ruby -e "p ('a.1'..'c.3').to_a"
["a.1", "a.2", "a.3", "a.4", "a.5", "a.6", "a.7", "a.8", "a.9", "b.0",
"b.1", "b.2", "b.3", "b.4", "b.5", "b.6", "b.7", "b.8", "b.9", "c.0",
"c.1", "c.2", "c.3"]
(The rest of the message was less relevant, so I snipped it along with
my irrelevant smart-ass replies :o) Instead, I present the current
state of affairs on this issue, as there seems to be a lot of confusion
about it:
There are two core issues involved in this problem. The first is
the dual nature of Ranges. Since Ranges implement the #each method,
they can be viewed as a set of elements, which is how Enumerable views
them. Therefore (1..10).to_a works, along with all of the other
wonderful methods that Enumerable provides.
Ranges can also be viewed as intervals. The best example here is
(1.0..10.0). This Range is *not* Enumerable, since Float does not (and
can not) implement the #each method. However, it is still useful to ask
if a number falls within the boundaries of a Range. Therefore, the <=>
operator is used to test for Range.begin <= value <= Range.end. This is
the functionality that is currently implemented by Range#member?, and
its alias, Range#include?. This was mainly done as an optimization,
since checking 1 <= x <= 1000000 is a whole lot faster than Enumerating
all 1000000 elements. It also allowed Float Ranges to work as well.
The other core issue is that the method String#succ is implemented
in such a way that it is possible for (x > x.succ) to be true (e.g. 'z'
'z'.succ). This is what makes the view of a Range as a set and the
view of a Range as an interval incompatible, and why
('1'..'10').include?('2') can be viewed as either right or wrong
depending on how you are looking at the Range. Certainly, '2' is in the
set ('1', '2', '3', ... , '10'), but '1' <= '2' <= '10' is *not* true
since strings are compared, well, as strings.
So, we are currently in a situation where Enumerable.member? (and
its alias Enumerable.include?) test for set membership by enumerating
the set through the #each method, but Range#member? and Range#include?
test for interval coverage and *not* set membership. This is the main
inconsistency that we are trying to get rid of.
Matz is currently considering changing the functionality of
Range#member? from an interval coverage test back to the set membership
test, which interestingly enough, is actually how it started life (it
was later change to be the same as #include?). Range would still
override the method and optimize the test for Integer Ranges, but
non-Integer ranges (include String Ranges) would revert back to the
Enumerable#member? method (or at least that method's functionality).
Matz hasn't decided whether he would change the Range#include? method to
be a test for set membership too, or to leave it as an interval coverage
test. My guess is that it will remain an alias for #member?, since the
two are aliases in Enumerable.
However, since Range#member? would no longer be an interval coverage
test, Matz would want to add a new method to Range to take its place, so
he is currently trying to find a good name for that method. Current
suggestions for the name include (no pun intended):
#between?
#betwixt?
@bound?
#cover?
#enclose?
#encompass?
#in?
#in_interval?
#in_range?
#inside?
#surround?
#within?
Matz is also seeking comments from other people on these suggested
names along with any other names that might be appropriate.
David A. Black also suggested (along with the wonderfully apt name
#encompass?) that this new function could also accept a Range as the
parameter and test for interval over interval coverage as well. This
sounds like a great suggestion and would make the new function even more
useful.
So, that's where we are. I hope this clears up a lot of the
misconceptions that seem to have plagued this discussion.
- Warren Brown