From: ptkwt@... (Phil Tomson)
Date: 2004-09-17T02:54:48+09:00
Subject: Re: Ex-Perl coders: Howz it feel to convert to Ruby?

In article <Pine.LNX.4.44.0409160342510.17156-100000@wobblini>,
David A. Black <dblack@wobblini.net> wrote:
>Hi --
>
>On Thu, 16 Sep 2004, ChrisO wrote:
>
>> Phil Tomson wrote:
>> >
>> > In Ruby you can have:
>> > 
>> > 
>> >   def foo
>> >     #...
>> >       yield
>> >     #...
>> >   end
>> > 
>> > Now there is no indication from looking at the method definition line (the 
>> > 'def foo' part) that any argument is passed to this method, yet it 
>> > requires that a block be passed to it, like so:
>> > 
>> >   foo { puts "Boo!" }
>> > 
>> > So, it's a bit like the problem I'm talking about with Perl, except that 
>> > in practice it's not as bad because usually there is only one yield in a 
>> > method - but it can be an issue.  That's why it's probably better to do:
>> > 
>> >   def foo(&b)
>> >     #...
>> >     b.call
>> >     #...
>> >   end
>> > 
>> > Because it provides the reader of the code with a clear indication that 
>> > the method takes a block.  Also, it's usually a good idea if you do use 
>> > yield to also call 'block_given?' prior to yielding.
>> > 
>> 
>> Yes, this is a better example of what I was talking about, and yes, you 
>> can provide better indication here in Ruby than in Perl, I have to 
>> admit.  So, to see the parallels, I'll bet you see a lot more of the 
>> simple yields in block handling method definitions in classes than you 
>> do in the form of you second example with the spiked out parameter and 
>> the param.call approach.  It's disciplined, well constructed code, but 
>> not everyone is like that.  Hence the Perl dilemma/diatribe here.
>
>There's nothing wrong with doing this the way Phil has, but there's
>also nothing wrong or undisciplined about using yield.  Let's not
>stigmatize people who use yield (for example, Matz and many of the
>other authors of the Ruby standard library) as undisciplined.  It's
>not a test of character; it's a programming idiom.  You can work
>around it if you don't like it, as Phil has shown, or you can use it,
>as others have shown, in the course of writing perfectly good and
>clear code.

>
>When you supply a block to a method, you need to know how the block is
>going to be called -- which means you'll probably either have written
>the method yourself, or consulted some documentation that explains how
>the method works.  So in practical terms, the use of yield vs. calling
>the block explicitly probably doesn't matter too much too often.  You
>can use whichever semantics you like.  
>
>

I agree totally.  I did not intend to stigmatize people for using 'yield'.
In fact, I tend to use 'yield' as often as the alternative.  I think I 
sometimes prefer yield because even though it tends to make the arguments 
to the method somewhat ambiguous, the intent can sometimes seem clearer in 
the body of the method (vs the 'call').


Phil