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.


Coey Minear