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