Dear Monks,

we've recently acquired a significant perl codebase that clearly has been growing "organically" for some time... As we need to integrate it into our existing systems and need to make sure we can maintain it long term, work to clean-up/refactoring has commenced.

One of the tasks is the "unused subroutine cleanup" (seems common - see here and here) or at least an identification of potential cruft. We thought that instead of a regexp massacre, we'd like to go for PPI

PPI however seems no tame beast. Documentation is terse and maybe outdated. At least when trying to set up some examples according to documentation, we fail (bitterly). From the docs in PPI::Document:

  # Find all the named subroutines
  my @subs = $Document->find( 
        sub { $_[1]->isa('PPI::Statement::Sub') and $_[1]->name }
        );
[download]

Eh - well - no sir. This will put some ARRAYREF into the first element of @subs and that's it. Dumpering that ARRAYREF reveals a monstrous PPI parse tree. Basically equivalent of the Perl DOM we had in first place. Of course, if we let print out $_[1]->name within the find sub, there the names are, but unfortunately you cannot simply return the name. So for now, the only workaround to get PPI to DWIM, would be to save the names within the find sub into some global variable. Like so:

my @subs;

$document->find( sub {
                     if($_[1]->isa('PPI::Statement::Sub') && $_[1]->na
+me()) {
                         push @subs, $_[1]->name();
                     }
                 });
[download]

That does the trick, but seems quite hacky, quite nonconformat to what the documentation says (but the docs seem to be wrong in that case anyway).

So the question is - are we missing some general concept of PPI, or are the docs wrong - or both?