(1) To make traverse reusable. You can change the action taken for every node without editing traverse. You can make traverse do two different things without writing two different versions of it. As BrowserUK's mentioned in his post, "By passing a sub to the traverse routine you can make it do things other than just printing."

(2) Same answer as above. Both will work,

(3) The sub needs to be provided the node on which it is to perform an action. Normally, the node would have been passed as a parameter. This alternate way is a bit more concise and has less overhead.

(1) To make traverse reusable. You can change the action taken for every node without editing traverse. You can make traverse do two different things without writing two different versions of it.

Hence, I could have done the following just as well --

sub traverse {
  # do yer stuff
  _print($_);
  traverse(..);
}

sub _print {
  my ($node) = @_;
  print ' ' x $node->{dept}, $node->{c_id}, ': ', $_->{comm}, "\n";
}
[download]

Which, I did, and it also works. Hence, passing an anon sub as a param seems to be just a fancy way of doing what I already know MTOWODI, no?

--

when small people start casting long shadows, it is time to go to bed

I personally think that the anon-sub call back is just cleaner looking, but it has a number of other benefits. The biggest of those is that it doesn't break or force you to do ugly things if traverse is in another package.

Other benefits: you don't clutter up your symbol table with global named functions that are only intended to be used in one place. Also: you can use traverse in different ways in the same application, rather than defining the callback globally.

I also think that defining a fallback is cleaner in this case: you just check the $code arg for definedness, rather than probing the caller's package. Scope is nice and closed.

How about I explain by example:

traverse($in, 0, 0, sub {print ' ' x $_->{dept},'-',$_->{comm},"\n";})
+;

... later in the code...

traverse($in, 0, 0, sub {$sth->execute($dept, $comm)});
[download]

By the way, the sub doesn't have to be anon:

sub _print {
   print ' ' x $_->{dept},'-',$_->{comm},"\n";
}

traverse($in, 0, 0, \&_print);
[download]

It's a feature, it has no side effects, so there's no reason to get rid of it, and there's every reason to keep it. If you don't want to explicitely specify it, create a wrapper:

sub print_tree {
   push(@_, 0, 0, sub {print ' ' x $_->{dept},'-',$_->{comm},"\n";});
   &traverse;
}

print_tree($in);
[download]

Passing an action in allows the parent node to determine the action rather than the local node determining the action.

---

Perl is Huffman encoded by design.

Consider the following nested-array-style tree and logic to traverse it:

my $tree = [ 1
           , [ 2
             , 3
             , [ 4
               , [ 5 ]
               , 6     ] ]
           , 7             ] ;

sub traverse {
    my ($nodefn, $tree, $depth) = @_;
    $depth ||= 0;
    $depth++;
    for (@$tree) {
        ref() ? traverse( $nodefn, $_, $depth )
              : $nodefn->( $_, $depth );
    }
}
[download]

sub count_nodes {
    my $count;
    traverse( sub { $count++ }, @_ );
    $count;
}

print count_nodes($tree), $/;
# 7
[download]

sub print_node {
    my ($leaf, $depth) = @_;
    print "  " x ($depth - 1), "* $leaf", $/;
}
[download]

traverse( \&print_node, $tree );
# * 1
#   * 2
#   * 3
#     * 4
#       * 5
#     * 6
# * 7
[download]

sub bfs_traverse {
    my ($nodefn, $tree, $depth) = @_;
    $depth ||= 0;
    $depth++;
    my @leaves   = grep !ref(), @$tree;
    my @branches = grep  ref(), @$tree;
    $nodefn->( $_, $depth ) for @leaves;
    bfs_traverse( $nodefn, [map @$_, @branches], $depth )
        if @branches;
}
[download]

bfs_traverse( \&print_node, $tree );
# * 1
# * 7
#   * 2
#   * 3
#     * 4
#     * 6
#       * 5
[download]

Cheers,
Tom

This is called refactoring. It's when you understand that you already solved that problem in one point of your code, and you do a favour to yourself and don't cut-and-paste, but you rather "summarize" what the two functions have in common into a common function that you call twice, in two different context and for two similar-but-different purposes. Why is this a favour to yourself? Because the very time you'll find a bug, you will not have to go hunting in your code to look for all places where you pasted the bug. Because you learn to give these factored-out functions meaningful names, that make your code easier to read and maintain. Because you'll be able to use the same function the next time you have a similar problem.

Sometimes this factoring excercise is done ahead, like in BrowserUK case. This normally happens when you "see" that an algorithm you're going to use would be really helpful in much other situations, and you prepare to reuse. But be lazy, don't look too much ahead, or you could possibly drawn in a sea of pain, where you spend most of the time in building up a beautiful library, and take 5x the needed time to solve your problem.

To be fair, this is what I've summarised from some answers to a previous question of mines: Writing general code: real world example - and doubts! (just to warn you, the first answers actually deal with the issue, then you can find interesting suggestions about tainting, but I understand that these would be a little OT here :)