Right to the point! I too love Ruby 1.9.1 and Matz! but...
Ruby 1.8 (excluding 1.8.7) and Ruby 1.9 are really two different languages,
I can deal with that as long as I know, and can control which of the two I'm
using at any given time for any given application.
Matz ceded maintenance of the "1.8" stream and moved on to 1.9 some time
ago. The 1.8.7 release, rather than simply fixing bugs and maintaining
compatibility, was attracted by "shiny objects" from 1.9 and wreaked havoc
on some important consumers of Ruby, exacerbated by the eagerness of
downstream package maintainers to keep up without understanding the
ramifications of the breach of the implication of compatibility between
versions with the same minor version number.
Ruby 1.8.6 represents the latest version of the old Ruby language, 1.9.1 is
the latest version of the new Ruby language, Ruby 1.8.7 is a mutant which
just muddies the waters.
···
On Wed, Feb 11, 2009 at 6:35 PM, Gregory Brown <gregory.t.brown@gmail.com>wrote:
On Wed, Feb 11, 2009 at 5:11 PM, _why <why@ruby-lang.org> wrote:
> Folks, I'd stay away from the heavy-handed approach with Matz. He
> doesn't respond to a mob. And despite all the hype and business that
> now revolves around Ruby, it's still the man's language and his life
> work.
Ah, but it's not Matz's issue. I actually love Ruby 1.9.1, and every
time I ask Matz about this he says "I don't maintain 1.8".
The issue is not with change, but with change that something that was
previously labeled non-changing in a defacto way .
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.
···
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}] = 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.
Jeremy Henty writes:
> >> 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.
>
> Regards,
>
> Jeremy Henty
>
As I read this, my feeling about what "most people" would expect
should fall into one of two categories:
- hashes should allow (different) hashes to be used as keys; or
- hashes should _not_ allow hashes to be used as keys.
If someone feels the first response is correct, then '100' would be
what they expect from Ruby. If someone feels the second response is
correct, then they would probably expect a SyntaxError or RuntimeError
exception to be thrown.
So from my perspective, having a hash with a hash as a key return
'nil' is a bug (in the example given above, where it was previously
set), and bugs should be fixed, in all versions. You are arguing from
the third camp of "I'm used to the bug so please don't fix it."
Of course, these are just my opinions. And in general, I do fall into
the "don't change the API behavior between 1.8.6 and 1.8.7" camp. But
in this case, I would say the 1.8.6 behavior described is a bug and
should be addressed.
Coey Minear
···
On 2009-02-11, Pit Capitain <pit.capitain@gmail.com> wrote:
I'm in the happy camp, mostly. It's fine to add new features to an upwardly compatible release as long as one doesn't sacrifice the stability(given this is a "production" release) - i.e., upwardly compatible does NOT mean that feature set of version x.y.z should be the same as the feature set of x.y.z+1. API compatibility across 'teeny' releases is important, and, is something Matz and others have professed(in a thread I don't have a pointer handy, but it's on ruby-core).
Fixes to bugs, IMO, cannot be counted as making the software incompatible - if they did, the language implementation would get nowhere.
On the other hand, changes to the existing APIs that are not generally accepted as bugs definitely count as incompatibilities - IMO, it's this area thats tinged with shades of gray, since I cannot easily tell if some 'bug fixes' are indeed 'bug fixes' or if they break the compatibility expectations that the Ruby versioning system sets.( I work for a Ruby vendor that, among other things, promises compatibility, and any mixed bag of fixes + compatibility breakages, if indeed it is so, is an issue to deal with).
Just my 2 cents,
-ps
Coey Minear wrote:
···
Jeremy Henty writes:
> 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}] = 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.
> > Regards,
> > Jeremy Henty
>
As I read this, my feeling about what "most people" would expect
should fall into one of two categories:
- hashes should allow (different) hashes to be used as keys; or
- hashes should _not_ allow hashes to be used as keys.
If someone feels the first response is correct, then '100' would be
what they expect from Ruby. If someone feels the second response is
correct, then they would probably expect a SyntaxError or RuntimeError
exception to be thrown.
So from my perspective, having a hash with a hash as a key return
'nil' is a bug (in the example given above, where it was previously
set), and bugs should be fixed, in all versions. You are arguing from
the third camp of "I'm used to the bug so please don't fix it."
Of course, these are just my opinions. And in general, I do fall into
the "don't change the API behavior between 1.8.6 and 1.8.7" camp. But
in this case, I would say the 1.8.6 behavior described is a bug and
should be addressed.
> >> 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.
···
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>:
OK, I accept your point for this particular change. It doesn't hold
for other changes, eg. methods returning Enumerators when they used to
return Arrays.
Regards,
Jeremy Henty
···
On 2009-02-12, James Coglan <jcoglan@googlemail.com> wrote:
[Note: parts of this message were removed to make it a legal post.]
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>:
> 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,
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.
OK, I accept your point for this particular change. It doesn't hold
for other changes, eg. methods returning Enumerators when they used to
return Arrays.
My only general complaint would be that I think that some releases may
have more bugs than others. Maybe a year ago, the ruby release candidate
for some 1.9.x version had an irb which segfaulted for me. The later
1.9.x irb didn't segfault anymore. Irb is quite important for me so I
was surprised to see irb has had difficulties.
My wish would be that the amount of bugs is kept to a minimum.
Annoyingly, no. I was repeating something I was sure had been said
elsewhere in these threads, but despite having trawled around my news
server and Google groups I can't find the post. So maybe I *have*
been spreading FUD after all. My apologies if so.
Regards,
Jeremy Henty
···
On 2009-02-13, Pit Capitain <pit.capitain@gmail.com> wrote:
2009/2/13 Jeremy Henty <onepoint@starurchin.org>:
OK, I accept your point for this particular change. It doesn't hold
for other changes, eg. methods returning Enumerators when they used to
return Arrays.
My apologies if so.