On Saturday 02 October 2004 10:12 pm, Gavin Sinclair wrote:
> > As a nuby, even when you *know* there's two ways to do something, you're
> > stuck wondering if there is some subtle reason that one is better (or
> > simply different) than the other. You see two mechanisms, can't find
> > anything written that describes when to use one or the other, and are
> > left puzzled and confused.
>
> Good point, Bob.  I normally baulk at sensitivity to TMTOWTDI, but
> this case registers clearly in my mind as a potential for confusion.
> I guess from now on, when instructing someone in this area, I'll show
> them both ways at the same time and deal with confusion upfront.
>
> Stylistically, I tend to favour 'yield' when a block is optional, and
> 'block.call' when it's not.
>
>   def foo(a, b, &block)
>
> visually suggests to me that a block is required.  I usually mark a
> method like this as well:
>
>   def foo(a, b)  # :yield: peanut
>
> I wonder what other people think/do?

I never use yield. But I'll tell you what, I too think the above suggests that 
&block is required. I really dislike inconsistency, so I even put in an RCR 
about it, to the effect that

   def foo(a, b, &block=nil)

would be needed to make the block optional. Matz said that it might be a good 
idea, but would break code.

But since then, I've completely flipped positions, and more in concert with 
the ideas of duck-typing, I wish all arguments worked like &block. e.g.

   def foo(a, b)
     "#{a}#{b}"
   end

   foo(1)  #=> "1"

Just as block is nil in the above, so would  b  here. Likewise:

  foo(1,2,3)  #=> "12"

and 3 would be ignored.

Among other things this would reduce the need for (instantiating a method 
object and) checking arity.

T.