If you call the thing "$c_ref" then sure, it did not give you any advantage over the ill-named keyword. If on the other hand you use a descriptive name, the code gets must more readable. The Ruby syntax gives you no hint about what is the block supposed to do, what is it supposed to accept or return, it doesn't tell you anything! On one side you hear rubystas babble about how bad the Perl default variable $_ is and then they use something like this for something conceptually much more complicated and give you no chance to name the thing should you feel the need to. Perl let's you write foreach (@array) as well as foreach my $meaningful_name (@array), Ruby doesn't give you a chance to name the coderef/closure. It doesn't even admit there's one. To make things even funnier, it doesn't even tell you the method accepts a coderef (or block if you will) and the only way to find out is to read the method's body. The (&) at least tells you the subroutine expects a block, Ruby doesn't tell you anything.

If you do not want to name the coderef, go ahead an use $_[-1]->(1), it's just as cryptic as yield.

BTW, please translate these two to Ruby:

sub search { my $wanted = shift; foreach my $path (@_) { print "Searching in '$path'\n"; find($wanted, $path); } } # I don't care about the File::Find ... how do you pass the block to a +nother subroutine/method?
sub walk_tree { my ($self, $branch_handler, $leaf_handler) = @_; if ($self->isLeaf()) { $leaf_handler->($self->{data}); } else { $branch_handler->{$self->{data}}; foreach my $child ($self->children()) { $child->walk_tree($branch_handler, $leaf_handler); } } }


Enoch was right!
Enjoy the last years of Rome.

In reply to Re^3: RFC: Simulating Ruby's "yield" and "blocks" in Perl by Jenda

and:  <code> code here </code>

  • Please read these before you post! —
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;