If you are happy with the direction of Ruby 1.8.7+, respond

[Coey Minear]

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

 

[Prashant Srinivasan]

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

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 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

 

[Rick DeNatale]

[Note: parts of this message were removed to make it a legal post.]

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.

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.

 

[Pit Capitain]

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

 

[Marc Heiler]

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.

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

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.