On Aug 4, 2010, at 1:35 PM, Myron Marston wrote: >> I wouldn't even bother to undef those methods. > > If we don't undef the methods, then the semantics of the > #module_eval_with_args (or whatever we call it) will be different on > 1.8.6 and other versions. On 1.8.6, a method definition in the block > would define both an instance method _and_ a class method. Someone > could write a spec against 1.8.6, and accidentally call the class > method, not realizing they've done this, and the spec wouldn't work on > 1.8.7 and above since the class method won't be there. So I think the > undefs are important, and I don't think it adds too much complexity. > >> Something like: >> >> def module_eval_with_args(*args, &block) >> if respond_to?(:module_exec) >> module_exec(*args, &block) >> else >> # custom solution >> end >> end >> >> At that point, as long as all the shared group specs are passing, we're >> good. Make sense? > > Makes total sense. I'll work on porting this to RSpec, and open an > github issue with a link to the commits when I'm done.
FYI - to those paying attention - I merged Myron's changes with support for parameterized shared groups even in 1.8.6. At this point, the customization block is still being eval'd after the shared block, and I'm fairly well convinced this is the right thing, in combination with params to the block. Next release will FINALLY have parameterized shared groups. Sweet! Cheers, David _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
