[rspec-users] Name collision - how would you handle this?
dchelimsky at gmail.com
Wed Aug 11 23:30:36 EDT 2010
On Aug 11, 2010, at 3:05 PM, Myron Marston wrote:
> Sorry it's taken me so long to respond--I have considerably less time
> on weekdays than the weekend to take care of things like this.
>> Yehuda Katz made a similar suggestion to me, referencing some code from merb:http://github.com/merb/merb/blob/master/merb-core/lib/merb-core/contr...
>> Merb also has an override! method that end users can use to override the registered reserved methods, which I agree would be a necessary part of this. The idea being that any user that does that does so explicitly and knowingly.
> Merb's implementation is very similar to what I had in mind. It's
> nice to see I'm not in left field with my idea :).
> I agree that having something like override! is important, although I
> think I slightly prefer an API like this:
> allow_reserved_overrides do
> def reserved_method
> Or maybe I like blocks too much...
>> The blacklist comment probably wouldn't work for upstream libs like Rails, Test::Unit or MiniUnit. It would be up to RSpec to define those lists. But maybe that's an acceptable tradeoff. WDYT?
> RSpec is pretty high-profile in the Ruby community, so we could
> hopefully get most libraries to add their reserved methods using
> something like:
> if defined?(RSpec::Core.add_reserved_methods)
> RSpec::Core.add_reserved_methods :foo, :bar, :bazz
> As far as Rails goes, rspec-rails seems like a natural point to
> register these reserved methods. For libraries that are distributed
> with ruby like Test::Unit, I think it's acceptable to register their
> reserved methods in rspec-core itself.
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).
> What do others think of this idea? I'm willing to take a stab at
> implementing this if there is support for 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.
Anybody else have opinions on this?
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users