I think they should all be registered in the same place, in rspec-core. Or are you saying that rspec-rails would take the responsibility of registering the names for rspec-rails, rails, test/unit and minitest? That makes sense to me, as long as they’re all using RSpec::Core::register_reserved_name (or whatever).
My suggestion is that rspec-rails would be responsible for registering
the names for rspec-rails and rails. Since test/unit and minitest can
conceivably be used with RSpec outside of rails, I think it makes
sense to make rspec-core responsible for registering the names for
them. I think everything that deals with this (including rspec-core
itself) would go through the RSpec::Core::register_reserved_name API
(or whatever we call it).
I’m still not sold on this idea yet. Seems like a lot of complexity for not much benefit. I’ve already taken care of the message issue by encapsulating the assertion libs in a separate scope.
I see two categories of reserved methods:
- Methods like should and should_not. It would cause a problem if
someone knowingly overwrote these as it would cause specs like “it
{ should do_something }” to fail, but it’s pretty obvious that these
methods are reserved, and unlikely that someone would need one of
these as a helper method. - Methods like message, where it’s not obvious that it’s a
reserved method, and it’s likely that someone will define this as a
helper method.
If all of the remaining reserved methods fall into the first category,
then I think that there really isn’t much need to add this. If we
have any remaining reserved methods in the second category, then I
think we should either solve it by refactoring code to remove the name
collision (as you did) or implement something like what I’ve
suggested.
For now we can hold off on this, and revisit if we ever learn of any
more reserved methods in the 2nd category.