On Aug 8, 2010, at 11:58 AM, Myron Marston wrote: > 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.
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/controller/merb_controller.rb#L508 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. 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? > Myron > > On Aug 8, 9:13 am, Matt Wynne <[email protected]> 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 >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> cheers, >> Matt >> >> http://blog.mattwynne.net+44(0)7974 430184 >> >> _______________________________________________ >> rspec-users mailing list >> [email protected]http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
