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

Dave Thomas wrote:
> 
> On Mar 26, 2008, at 5:10 PM, David Flanagan wrote:
>> I'm not saying I agree with the current behavior.
> 
> Then now's the time to change it, I'd say...
> 

I can see your point if you believe that it was a bug or a regression 
that we ended up with the current behavior.  But I tend to assume that 
Matz makes changes like these after careful thought, and that there are 
nuances here that are not apparent to us now.  If we don't understand 
the reason for the change in the first place, it seems cavalier to argue 
for changing the behavior back.  I can imagine, for example, that there 
is a strong argument to be made that it is important that all numeric 
ranges x..y should have the same behavior regardless of whether x and y 
are Integer or Float values.

>> 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.
> 
> We've added two entire classes to the built-in list since the 1.9.0 
> release, and added many, many methods to array, string, and so on, so I 
> don't think that argument really holds. 

Additions are much different than backward-incompatible changes.  And I 
think "many, many methods" is overstating things.  I don't have a 
12/25/2007 build right now, but comparing an older one from late 2007 to 
the current build, I see any changes to Array except for the removal of 
to_splat.  There are a handful of new methods in String, but given that 
the encoding stuff wasn't complete for the Christmas release, that isn't 
surprising.

We should do what's right for
> the language _before_ 1.9 is truly frozen (if that ever happens). And, 
> as authors, we accept that our some of our descriptions will gradually 
> become incorrect (as happened to the second edition of the PickAxe when 
> the member? change was made in 1.8.6. The sky didn't fall then, and the 
> sky won't fall now.) 

A healthy perspective...

We all agree (I think) that member? is not
> currently doing what its name promises, and fixing it now is a lot 
> easier than fixing it later.

I'm not going to try to argue that member? is correct, but I'm not so 
quick to assume that it is incorrect, either.  In any case, in my 
opinion it is unfixable.  I think that changing this method *again* 
would not be best for the language.  Maybe deprecating it and replacing 
it would be best, but I don't think it should change.

	David

> 
> Cheers
> 
> 
> Dave
> 
>