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