artist has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,
Listing of subs and methods of modules would be really helpful to increase the usability of the modules in general. Talking in CB, tye provided 'm class' and 'x \%INC' commands for perl -d 'filename.pl' to check the methods and classes loaded repspectively. How I can access similar info via a program with or without 'use'ing the multiple modules for which I am looking the methods/subs ?. Something better then perldoc or looking at module docs. I know that not all the run-time methods will be available.

Thanks,
artist

Replies are listed 'Best First'.
(jeffa) Re: Module Subs and Methods
by jeffa (Bishop) on Jun 19, 2003 at 19:18 UTC
    I disagree that simply listing names increases a module's usability. Good examples of how to use the subs - now that is useful. But if it's a list of subs you want, you can use the following *NIX one-liner:
    perl -MDevel::Symdump -le'eval"require $ARGV[0]";print for Devel::Symd +ump->new($ARGV[0])->functions' HTML::Parser
    UPDATE: or this (more) complete script:
    use strict; use warnings; use Devel::Symdump; my $class = shift || die "need module name"; eval "require $class"; my $obj = Devel::Symdump->new($class); print $_,$/ for $obj->functions;
    Don't forget that some CPAN author's follow the convention of prepending underscores to 'private' subs - you can filter those out easily with grep:
    print $_,$/ for grep ! /::_/, $obj->functions;
    should do the trick.

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    
Re: Module Subs and Methods
by BrowserUk (Patriarch) on Jun 19, 2003 at 20:53 UTC

    Try saving this to a file in your perl/lib/Devel/ directory as SubCheck.pm

    use strict; package DB; CHECK{ print "$_ => $DB::sub{$_}" for sort keys %DB::sub; die 'Done'; +} sub DB{ return; } 1;

    Then invoke a program that uses the modules you are interested in exploring using the following syntax:

    perl -d:SubCheck yourscript.

    You will get output that looks something like this (for a very simple program).

    The output is of the form packagename::subname => sourcefile:startline-endline.

    The list should include all the subs the compiler knows about just prior to running the program. The program will not be run.

    I guess this could be a candidate for uploading to CPAN if anyone would find it useful. Hardly seems worth it for 6 lines of code though?


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


      The list should include all the subs the compiler knows about just prior to running the program. The program will not be run.**

      That's a very important distinction, as nothing dynamic (ie. run-time evaluated) will be listed.

      For example, CGI is probably the most well known example of dynamic autoloading. If you were to use CGI in your program and then run this, you’d see only a very small selection of the function available. However with use CGI qw(-compile :all) it would list them all. That's because, by default, CGI only compiles a function when it’s requested.

      Update: A simpler example is require Module::Name if $foo

      Any method to list functions will always be suspect due to dynamic evaluation. Add in anonymous subs and the waters are even murkier. This isn't a failing in BrowserUK’s method (which is pretty damn cool), it’s a reality of Perl.


      ** Not completely correct as the BEGIN{} block will be run. (Yes I’m picking nits :)

      If you want to play with the symbol table then Devel::Symdump provides lots of potential amusement.

Re: Module Subs and Methods
by chip (Curate) on Jun 19, 2003 at 19:22 UTC
    You can't get there from here. Only Perl can parse Perl. So until you've loaded the module, no one can know all the subs and variables that module will provide.

    I suppose if you really wanted to you could grep the module source for:

        /^ \s* sub \s+ (\w+) \s* [({] /x

    But that would miss a lot.

        -- Chip Salzenberg, Free-Floating Agent of Chaos

Re: Module Subs and Methods
by graff (Chancellor) on Jun 20, 2003 at 03:28 UTC
    In response to another similar question, I wrote this little utility script for inspecting sub definitions and sub calls in perl source code. It's more than a one-liner, but not more than a couple hours worth of work (so, don't expect it to be really thorough -- but at least the explanation that comes with it is "accurate", I hope).

    I would be interested to find out which modules you want to try it on, and whether it is helpful from your perspective.

Re: Module Subs and Methods
by gellyfish (Monsignor) on Jun 20, 2003 at 10:58 UTC

    Something better then perldoc or looking at module docs.
    In my opinion (and I have no doubt in others too) there is nothing better than the modules documentation. This is the published interface of the module and if a method doesn't appear in the documentation then really you shouldn't care about it - how I would love to say this were true of all the modules on CPAN. If you are finding modules wherein not all the public methods are documented might I suggest that you fix this yourself and send the patch to the modules author.

    /J\