From: David Flanagan <david@...>
Date: 2008-03-27T07:10:52+09:00
Subject: Re: Recent changes in Range#step behavior

Dave Thomas wrote:
> 
> On Mar 26, 2008, at 3:48 PM, David Flanagan wrote:
>> 2) I don't believe it is correct to regard Ranges as sets of values. 
>> They are something different and can have continuous or discrete 
>> behavior depending on how they are used.  If you define a range as a 
>> kind of set, then the behavior of include? and member? seems wrong.  
>> But  if you instead look at how those methods behave in 1.8 and 1.9 
>> then it becomes clear that a range is not a set.
> 
> David:
> 
> By definition, ranges are defined for all objects other than a few 
> built-in ones to use succ() and comparisons. 

The "few built-in ones" include Fixnum, which is probably the most 
commonly used case by far.  You can't treat Fixnum as an edge case.

Thus they are by definition
> a representation of a set of values. 

A finite set of discrete values, or an infinite set of continuous 
values?   And by whose definition?  I imagine that the current rdoc 
comments came from the first edition of your book. But the behavior of 
the class (since sometime in the 1.8.x series) argues that ranges with 
numeric endpoints are not really like sets.  In Ruby, I think that the 
MRI implementation is the ultimate "definition".

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.
> 

I'm not saying I agree with the current behavior.  But I don't think 
that changing it now would be wise. Especially since it has already 
changed once.  If that previous change was a mistake and current 
behavior is a bug that has gone undetected for years then it should be 
fixed in 1.8 as well as 1.9.  But I suspect that this is not the kind of 
thing that can safely be changed in a 1.8.x point release--it would 
break too much code.

This would have been something to fix during the lead-up to 1.9.0 when 
cover? was being introduced.  But 1.9.0 has been released, and the Ruby 
1.9 API is, in theory, frozen. In practice, of course, changes are still 
being made, but the bar is presumably much higher now.  Introducing a 
new method to complement cover? and guarantee discrete comparison would 
be one thing, but changing an existing method in an incompatible way is 
a much bigger deal!

	David