On 7 Aug 2010, at 22:10, David Chelimsky wrote: > 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.
While I fully agree if you `def` a method that already exists, you should be expected to deal with it yourself (that's just the way things are in Ruby), does the same apply to `let`? I can actually see an argument that you should only be able to `let` a method that doesn't already exist, and also only do it once (which is just a consequence of not being able to override a method, given the current implementation). Can you think of any downsides of preventing RSpec users from overriding existing methods with `let`? Are there any popular names already taken? Or other problems? To me, `let` is magic. I don't think of it, first and foremost, of defining a method. I see the things it creates as more like local variables, and just remind myself that they're methods if I wonder why it works. I'm not sold either way on this, but I think it's one worth a debate. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
