blocks - too close an association?

[David Harrigan]

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

 

[Christophe Grandsire]

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?

I may be the one missing something here but what is the difference betwee=
n
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 numb=
er and
kind of parameters it needs, don't you? Well, blocks are just another par=
ameter,
with a special syntax to make the common case of calling just one block n=
icer
looking and simple to understand. So when you learn the signature of a me=
thod
in Ruby, you learn all the parameters it asks for, what they mean, whethe=
r they
are mandatory or optional, and that includes a possible block and the arg=
uments
it itself takes.

Frankly, I don't know why having to know that File:pen needs two string
parameters containing the name of the file and the opening mode is differ=
ent
from having to know that it also takes a block which takes the file handl=
e of
the open file as argument. And if you check the API in for instance
http://ruby-doc.org/core, you'll see that the presence of a block (and it=
s
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 Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[David A. Black]

Hi --

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?

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