2009/2/12 Jeremy H. [email protected]
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.
On 2009-02-11, Pit C. [email protected] wrote:
2009/2/11 Rados?aw Bu?at [email protected]:
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 H.
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
Jeremy H. writes:
On 2009-02-11, Pit C. [email protected] wrote:
2009/2/11 Rados?aw Bu?at [email protected]:
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 H.
As I read this, my feeling about what “most people” would expect
should fall into one of two categories:
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 M.
On Thu, Feb 12, 2009 at 10:59 AM, James C.
[email protected]wrote:
Ah, you mean Hash#hash. Thanks a lot, I didn’t know that. But this
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
result as 1.8.6 . That is the point.
I did not know 1.8.6 returned the counterintuitive result. Hence…
On 2009-02-12, James C. [email protected] wrote:
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.
Regards,
Jeremy H.
I am indifferent to it, may I post here as well? 
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.
2009/2/13 Jeremy H. [email protected]:
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.
Jeremy, can you show us an example?
Regards,
Pit
On Wed, Feb 11, 2009 at 10:12 AM, Gregory B.
[email protected]wrote:
This one is for those who wish that Ruby 1.8 would go back to being
1.8.6 compatible in Ruby 1.8.8. If you agree with this, share your
thoughts or at least a simple ‘+1’. If you disagree, please find the
other thread titled ‘If you are happy with the direction of Ruby
1.8.7, respond’. If you are in the middle, I don’t know what you
should do… write two posts?
If you ask me, what the Pythonistas got right that Ruby 1.8.7+ does not
is:
from future import x
I think it’s great that Ruby 1.8.7+ wants to include all these nifty 1.9
features. But, I don’t think they should be “on” by default.
I think it’d be great if certain features (e.g. the 1.9.x enumerators)
were
available if you were to, say, require “future/enumerator” or something.
If that were the case, I’d be on board with backporting everything,
although
changes to the grammar of the language itself might be difficult to
enable
in this manner, and many bring backwards compatibility issues.
On 2009-02-13, Pit C. [email protected] wrote:
2009/2/13 Jeremy H. [email protected]:
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.Jeremy, can you show us an example?
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 H.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs