# Blocks - too close an association?

**URL:** <https://www.ruby-forum.com/t/blocks-too-close-an-association/48490>\
**Category:** Ruby\
**Created:** [November 21, 2005, 12:05pm UTC](https://www.ruby-forum.com/t/blocks-too-close-an-association/48490 "2005-11-21T12:05:49Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dharrigan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e19b73/32.png) [@dharrigan](https://www.ruby-forum.com/u/dharrigan)\
**Post date:** [November 21, 2005, 12:05pm UTC](https://www.ruby-forum.com/t/blocks-too-close-an-association/48490/1 "2005-11-21T12:05:49Z")

</div>

Hi,

I’m getting my head around blocks, closures etc in Ruby - I’m from a  
Java background. Now, I’m reading the book “Programming Ruby - The  
Pragmatic Programmer’s Guide” and in the section titled “Blocks for  
Transactions” there is an example of using a block for a file  
operation. However, examining this code, and especially with a view of  
hiding detail from a receiver, I find myself in some puzzlement,  
because of this reason:

Another object simply can’t call  
File.openAndProcess(“another\_testfile”, “r”) WITHOUT knowing that one  
also has to write a block because inside openAndProcess there is a  
“yield”. This means that the method openAndProcess isn’t that  
invisible, the callee must have some detailed knowledge about the  
method (i.e., the fact that it calls a yield) so that they can write a  
block.

Am I missing something here?

-=david=-

---

<div class="post-metadata">

**Author:** ![dharrigan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e19b73/32.png) [@dharrigan](https://www.ruby-forum.com/u/dharrigan)\
**Post date:** [November 21, 2005, 12:29pm UTC](https://www.ruby-forum.com/t/blocks-too-close-an-association/48490/2 "2005-11-21T12:29:56Z")

</div>

Selon David H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> 

I may be the one missing something here but what is the difference  
between  
knowing that a method needs a block and knowing that it needs any other  
parameter? When you want to use a method, you need to know about the  
number and  
kind of parameters it needs, don’t you? Well, blocks are just another  
parameter,  
with a special syntax to make the common case of calling just one block  
nicer  
looking and simple to understand. So when you learn the signature of a  
method  
in Ruby, you learn all the parameters it asks for, what they mean,  
whether they  
are mandatory or optional, and that includes a possible block and the  
arguments  
it itself takes.

Frankly, I don’t know why having to know that File::open needs two  
string  
parameters containing the name of the file and the opening mode is  
different  
from having to know that it also takes a block which takes the file  
handle of  
the open file as argument. And if you check the API in for instance  
[RDoc Documentation](http://ruby-doc.org/core), you’ll see that the presence of a block (and  
its  
arguments) is described in the API. It’s just a method argument. It  
doesn’t  
reveal more detail about the method than any other method argument.

## Am I missing something here?

Christophe G…

[http://rainbow.conlang.free.fr](http://rainbow.conlang.free.fr)

It takes a straight mind to create a twisted conlang.

---

<div class="post-metadata">

**Author:** ![dharrigan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e19b73/32.png) [@dharrigan](https://www.ruby-forum.com/u/dharrigan)\
**Post date:** [November 21, 2005, 2:27pm UTC](https://www.ruby-forum.com/t/blocks-too-close-an-association/48490/3 "2005-11-21T14:27:13Z")

</div>

Hi –

On Mon, 21 Nov 2005, David H. wrote:

> Another object simply can’t call  
> File.openAndProcess(“another\_testfile”, “r”) WITHOUT knowing that one  
> also has to write a block because inside openAndProcess there is a  
> “yield”. This means that the method openAndProcess isn’t that  
> invisible, the callee must have some detailed knowledge about the  
> method (i.e., the fact that it calls a yield) so that they can write a  
> block.
> 
> Am I missing something here?

You make it sound like yielding to a block is a method’s dirty secret  
🙂 The caller is _supposed_ to know how to call the method – so if  
your method takes a block, you would say so in the documentation. For  
example, here’s part of the ri output for Array#each:

* * *

## Array#each array.each {|item| block } -\> array

```
  Calls _block_ once for each element in _self_, passing that
  element as a parameter.

```

David