Good error messages are important to a library's usability. Could we find away to give the user a good error message when they override a "reserved method"?
I'm thinking this could be accomplished with 2 simple pieces: 1. A method_added hook in Rspec-core that gives a warning or error when a reserved method is overridden. 2. An API that allows libraries to add to the reserved methods list. That way, rspec doesn't have to have knowledge of other libraries; it would be the responsibility of other libraries to add their reserved methods to the list. Myron On Aug 8, 9:13 am, Matt Wynne <m...@mattwynne.net> wrote: > On 8 Aug 2010, at 16:53, David Chelimsky wrote: > > > > > > > On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: > >> On 8 Aug 2010, at 16:38, David Chelimsky wrote: > >>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: > > >>>> Hey all, > > >>>> It turns out that if you have > > >>>> * Rails (2 or 3) > >>>> * Ruby-1.9 > >>>> * a model named Message > >>>> * let(:message) or def message in an example group > >>>> * a Rails assertion in an example in that group > >>>> * note that rspec-rails' matchers delegate to Rails' assertions > > >>>> You'll get an error saying "wrong number of arguments (1 for 0)" > > >>>> This is because the rails assertion, which, when running with Ruby-1.9, > >>>> delegates to Minitest::Assertions#assert_block, which delegates to a > >>>> message() method that it defines. So the message() method defined by > >>>> let() overrides the message() method in the Assertions module, and > >>>> results in unexpected and undesirable outcomes. > > >>>> So - what should we do? I don't think changing Minitest is really an > >>>> option, as too many assertion libraries already wrap Minitest > >>>> assertions. I don't think RSpec should be in the business of monitoring > >>>> methods end-users define to make sure they're not overriding > >>>> pre-existing methods (what if you override a method intentionally?). The > >>>> only thing I'm left with is document this particular case and hope for > >>>> the best, but that feels unsatisfactory as well. > > >>>> Recommendations? Words of wisdom? > > >>> FYI - here's the issue that spawned this > >>> thread:http://github.com/rspec/rspec-rails/issues/152 > > >> Can you use the Assertions module some other way than mixing it into the > >> example (thereby polluting it with the Assertions module's methods?) > > > I like the idea in the abstract, but most of the rails assertions rely on > > some state that is local to the example (@response, @controller, @request, > > etc, etc). RSpec _could_ gather up all those instance variables and pass > > them into an assertion-wrapper object, but then it would be highly coupled > > to that implementation and would lead us down a familiar and unfriendly > > path of forcing rspec-rails releases for every rails release. That's a > > world I hope to leave behind with Rails 3 :) > > So leave the rails assertions mixed into the example, but forward all the > calls to the MiniTest::Assertions methods to some other object that has them > mixed in. Won't that work? > > > > > It would also eliminate the option to use the Rails assertions directly in > > examples. > > > Oh, well :) > > >> cheers, > >> Matt > > >>http://blog.mattwynne.net > >>+44(0)7974 430184 > > > _______________________________________________ > > rspec-users mailing list > > rspec-us...@rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > cheers, > Matt > > http://blog.mattwynne.net+44(0)7974 430184 > > _______________________________________________ > rspec-users mailing list > rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
