Mad behaviour of String#hash

AdamB

I recently fixed a bug in LightUp that was the result of a subtle change in the method #hash between Ruby 1.8 and 2.0 that I thought I'd share.

Previously, "adam".hash would always give the same result - because its a hash of the string "adam" - which is what you'd expect.

Ruby 2.0, chooses to give you a different result every time you launch Ruby. Which is quite idiotic.

The upshot is you cannot rely on creating digests that persist across sessions.

Sadly, there is no doubt a thread somewhere in Rubyland explaining why its a stroke of brilliance.. sigh

Dan Rathbun

@adamb said:

Sadly, there is no doubt a thread somewhere in Rubyland explaining why its a stroke of brilliance.. sigh

Try:
https://bugs.ruby-lang.org/search?utf8=%E2%9C%93%26amp;q=String%23hash

TIG

Or for an explanation see this http://stackoverflow.com/questions/6783811/why-is-ruby-string-hash-inconsistent-across-machines

tt_su

Oh... I might have to have a scan of my extensions. I'm not sure if I store string hashes, but I wouldn't be surprised.
This .hash change affects only String, yes?

Thanks for the heads up.

Dan Rathbun

@tig said:

Or for an explanation see this http://stackoverflow.com/questions/6783811/why-is-ruby-string-hash-inconsistent-across-machines

Which actually quotes from the Ruby bugs dB at:
Bug #4103 (Closed): String#hash not returning consistent values in different sessions

Dan Rathbun

@tt_su said:

This .hash change affects only String, yes?

The above Ruby bugs thread mentions Object#hash being overhauled (which is inherited by every object, unless overriden.)

So a test under SketchUp 2014 & Ruby 2.0:

(1) Open a SketchUp session, and in the console:
Sketchup.hash %(#004000)[>> -112701995]

This is the method that the Module class inherits from Object.

(2) Close this SketchUp session, reopen SketchUp, and in the console:
Sketchup.hash %(#004000)[>> -226388390]