Points I'd raise:

1. In my experience, very little real-world Ruby code uses 
'block_given?'. If it needs to yield, it just yields. I'd consider this 
to be a case of duck-typing.

With yield you get a run-time error if no block was passed, but that's 
only one of a much larger set of method call errors (such as calling a 
method with argument of the wrong type).

Consider also that very little code tests 'a.respond_to? :foo' before 
calling 'a.foo'.

2. If a method uses &blk or Proc.new or yield, I'd say it's fairly safe 
to assume that the block *may* be called (at least from the point of 
view of automated documentation). Since it's unprovable in general even 
whether the method returns or not, it seems like hard work (for little 
benefit) to try to decide whether a method which accepts a block *never* 
actually calls it.

3. As you're undoubtedly aware, Ruby is so dynamic that you can't 
analyse a method in isolation anyway. You can decide that a bareword 
like 'foo' is a method call, but you don't know what that method will 
actually do when the program is run - it could be redefined dynamically, 
either within a class or on single objects (in their singleton class).

# in file one
class Foo
  def foo
    true
  end
  def bar
    yield 123 if foo   # yields, obviously
  end
end

# in file two
a = Foo.new
def a.foo; false; end
a.bar { |x| puts "I got #{x}" }   # actually it doesn't

That's an admittedly contrived example, but dynamic method definition 
occurs quite a lot in real applications, e.g. web frameworks like Rails.

Regards,

Brian.

-- 
Posted via http://www.ruby-forum.com/.