Hi --

On Mon, 6 Dec 2004, Brian [ISO-8859-15] Schr?der wrote:

> On Sun, 5 Dec 2004 05:37:26 +0900
> "David A. Black" <dblack / wobblini.net> wrote:
> 
> > Hi --
> > 
> > On Sun, 5 Dec 2004, Brian [ISO-8859-15] Schr?der wrote:
> > 
> > > On Sat, 4 Dec 2004 09:32:39 +0900
> > > "Joe Van Dyk" <joe.vandyk / boeing.com> wrote:
> > > 
> > > > I come from a heavy C++ background, discovered Ruby a few months ago and
> > > > love it.
> > > > 
> > > > I've found that using blocks is a very natural thing.  However, I have
> > > > not once used 'yield'.  I'm sure that there are events when using yield
> > > > would be helpful, but I have no clue when it would be appropriate to use.
> > > > 
> > > > Thoughts?  When do you use the 'yield' statement in code?
> > > > 
> > > > Joe
> > > 
> > > Yield is just a shortcut for block.call. 
> > > 
> > > If I am Lazy, and I don't need to pass the block further I use yield. But I
> > > believe that normally using block.call is more explicit and therefore
> > > preferable. 
> > 
> > 'yield' is equally explicit, and equally unambiguous.  It tells you
> > exactly as much as block.call does.  I wouldn't worry about the
> > laziness part of it; if you measure laziness by power per word of
> > code, all Ruby programmers are already massively lazy :-)
> > 
> > 
> 
> I see it as not as explicit, as it does not document in the method signature
> that the message takes a block.

That actually doesn't tell you much, though, in practical terms.  Any
method can have a &block argument, whether it calls it or not -- but,
more importantly, the presence of a &block argument doesn't tell you
what the block actually does.  So its value as documentation is
somewhat limited; you still have to either read the code or the
documentation before you can call the method properly.  


David

-- 
David A. Black
dblack / wobblini.net