…oo::Hash. When you name a nested constant that ends in a name that matches a top-level constant (such as "Foo::Hash"), rspec-fire was verifying the presence of a stubbed method on ::Hash if "Foo::Hash" was not defined. 1.9's const_get/const_defined? accepts a flag argument to have it ignore inherited/top-level constants, but 1.8 doesn't accept this argument, so we have to conditionally define methods to handle this properly.
Yes, I usually write my method stubs using symbols, but wandered from that path with some simple metaprogramming. RSpec's fine with strings, but rspec-fire wasn't when it came to running my full test suite - it insisted the methods did not exist on the real classes.
rspec/rspec-mocks#146 Note that this removes support for rspec 2.0...2.10 (and rspec 2.11 isn't out yet), but there's no reason to maintain stub_const logic here now that it has been ported to rspec-mocks, and if you're updating to the latest rspec-fire than we assume you're probably doing the same with rspec.
Previously, if you used both fire_double("Foo") and fire_replaced_class_double("Foo"), and Foo was not defined, stubbing or mocking a method on the fire double would fail because ConstantStubber.original_value_for returned nil for "Foo" (since it was originally unloaded), but the constant lookup would succeed and it would try to verify the implementation against the class stub. Now, ConstantStubber.find_original_value_for yields if the given class has been stubbed, and the value it yields can be nil if it was originally unloaded. This allows us to support this edge case.
This allows fire_double and fire_replaced_class_double to both be used in the same example with the same doubled class.