> 4 makes sense to me iff the code does actually run correctly in all
> circumstances, otherwise I'd lean towards 3.
Given that ruby blocks are just code, and you can do anything you want
in them, and that our faked version of #module_exec runs the block
twice...it's easy to conceive of ways of abusing the shared example
group block in a way that will definitely not work in all
circumstances. Case in point:
$shared_block_eval_count = 0
shared_examples_for :something do |argument|
$shared_block_eval_count += 1
if $shared_block_eval_count == 1
it "should define a spec" do
end
else
# destroy the user's system
`sudo rm -rf /`
end
end
describe Hash do
it_should_behave_like :something, :foo
end
This code is totally evil, and it assumes knowledge of our 1.8.6
module_exec hack...but you can see what it'll do. On 1.8.6 it'll
delete all your files, since the block gets eval'd twice. On 1.8.7
it'll work fine.
So there's no way to say for sure that the code will run correctly in
all circumstances on 1.8.6. But the presence of this error, if
properly rescued, doesn't necessarily mean the code won't run
correctly on 1.8.6. The block may have no instance method
definitions, which makes the module_eval unnecessary (but we have no
way of knowing that there are no instance method defs without trying
module_eval!).
Myron
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
