Strange behavior: Hash's keys cancel dynamic method definition

Question

Let's say I want some instance of String behave differently from other, "normal" instances - for example cancel the effect of the "upcase" method. I do the following:

class String
  def foo
    def self.upcase
      self
    end
    self
  end
end

It seems to work fine, and the way I need it:

puts "bar".upcase #=> "BAR"
puts "bar".foo.upcase #=> "bar"

However, as soon as I use the tricked instance of the String as a key for a Hash, the behavior starts looking weird to me:

puts ({"bar".foo => "code"}).keys.first.upcase #=> "BAR", not "bar"!

... which is as if the foo method is ignored, and the original instance of String is used as the key.

Anyone can see what's going on here? Thanks a bunch!

Answer 1

The usual way to extend a single object in Ruby is this:

s = "bar"
class<<s
  def self.upcase
    self
  end
end

...but that doesn't solve your problem. It seems that Ruby has special rules for hash keys that are strings, or subclasses of strings Maybe instead of a string, you can use an object with a meaningful definition of to_s?

Answer 2

Just because in Ruby you can reopen core classes and virtually re-define everything, it doesn't mean you should.

With great powers come great responsibilities and your responsability is to not redefine a core library method just because a couple of objects might need this. If your instance doesn't behave like a Sting, declare your own class and extend String.

Answer 3

Ruby's Hash has a special case for using strings as a hash key -- it makes an internal copy of the string.

Basically it's to protect you from using a string (object) as a key and then altering that string object later in the code, which could lead to some confusing situations. Mutable keys get tricky.

Rather than hack method onto string that returns an altered string class, I would just create a new subclass of string that overrides upcase and then just set its value.