From: Gavin Sinclair <gsinclair@...>
Date: 2004-10-03T11:12:26+09:00
Subject: Re: Too Many Ways?

On Sunday, October 3, 2004, 3:34:57 AM, Bob wrote:

>> And if you use the first syntax, there is the leap you have to make sooner
>> or later: "hang on - how do I pass this block to another method?"; or
>> conversely, "I have a proc object, but how do I pass it to a method which
>> expects a block?"

> Well, yes, I got hung up on this right off the bat--I got it into my
> head that yield was somehow dynamic, so that it would find some magic
> block up the stack to yield to . So I was very puzzled when I couldn't
> yield from within a method called by the method with the block.

> I had assumed this level of dyanmicity since the block wasn't 
> specified--it seemed obvious to me that objects would be simply invoked
> in a context where a yield would magically invoke some block defined
> somewhere.

> If I'd had to declare the block from the start, then this would never
> have been an issue.

> 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?

Cheers,
Gavin