--00163646ca446d866b0462bc69c1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Feb 12, 2009 at 10:59 AM, James Coglan <jcoglan / googlemail.com>wrote:

> 2009/2/12 Jeremy Henty <onepoint / starurchin.org>
>
> > On 2009-02-11, Pit Capitain <pit.capitain / gmail.com> wrote:
> > > 2009/2/11 Rados?aw Bu?at <radek.bulat / gmail.com>:
> > >> h
> > >> h[{"foo" 1}]  00
> > >> 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--