From: Rick DeNatale Date: 2009-02-13T02:53:05+09:00 Subject: Re: If you are happy with the direction of Ruby 1.8.7+, respond --00163646ca446d866b0462bc69c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 12, 2009 at 10:59 AM, James Coglan wrote: > 2009/2/12 Jeremy Henty > > > On 2009-02-11, Pit Capitain wrote: > > > 2009/2/11 Rados?aw Bu?at : > > >> h={} > > >> h[{"foo" => 1}] = 100 > > >> p h[{"foo" => 1}] > > >> > > >> ruby 1.8.6 prints "nil", 1.8.7 prints "100". > > > > > > Ah, you mean Hash#hash. Thanks a lot, I didn't know that. But this > > > is an example where the 1.8.7 version yields the result most people > > > would expect, > > > > No it doesn't. Most people would expect 1.8.7 to yield the same > > result as 1.8.6 . That is the point. > > > > Though I fall on the 'unhappy' side, this change is clearly fine: 1.8.6 > behaviour is clearly a bug and should be fixed, that's the point of bug fix > releases. Relying on buggy behaviour is a bad idea, and so is making > changes > to ostensibly correct behaviour in minor releases. > The problem is that one man's bug is another's breaking change. Lot's of people always found the fact that Strings acted like collections of character codes rather than characters as a bug. >ruby -e'p "abc"[0]' 97 fixed by 1.9 >ruby1.9 -e'p "abc"[0]' "a" But there is a lot of Ruby <1.8.7 code whose correct behavior depends on that "bug" considering it part of the old Ruby language definition. And there's lots of history of that behavior being defined not as a bug but as the way that Ruby works. The problem with making semantic changes like this, whether they are pseudo-bugfixes or not, is that it's very hard to sort out ahead of time what impact they will have on the installed base of code using the 'stable' version. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale --00163646ca446d866b0462bc69c1--