If your thinking about emulating perldoc, I'm wondering what you really need to realize...

Just a suggestion: The book Perl Hacks Hack #45 describes how to implement docstrings using Attribute::Handlers. (with a package "Attribute::Docstring" which unfortunately is not on CPAN* ) This allone should work with just compiling the code, and you can introspect all subs and package-vars directly!

Alternatively you may add a simple static parser which reads the docstrings like sub name :Doc( 'documentation text ...' ) { } without even compiling.

For me, this looks much easier than emulating perldoc.

UPDATE:
(*) But here perl_hacks_examples.tar.gz /object_hacks/add_information_with_attributes/lib/Attribute/Docstring.pm

Smart Docs in PerlySense does someting that sounds very similar to what you want.

Pressing C-o C-d on a method name will try to find it and display the sub/method POD in the echo area (screen shot).

The PerlySense command line script can only output Emacs elisp and Vim dictionary data structures at the moment, but it should be trivial to just get the POD text.

Actually, here's a minimal script to do that. Install Devel::PerlySense and save this into psdoc.pl:

#!/usr/bin/perl -w
use strict;
use warnings;
use Devel::PerlySense;

{
    my ($module_name, $sub_name) = @ARGV;
    $module_name &&  $sub_name or die("Syntax: $0 MODULE SUB\n");

    my $ps = Devel::PerlySense->new();
    my $class = $ps->classByName(name => $module_name, dirOrigin => ".
+")
            or die("Could not find module ($module_name)\n");

    my $location = $class->oLocationMethodDoc(method => $sub_name)
            or die("Could not find sub ($sub_name)\n");

    my $pod_text = $location->rhProperty->{text} || "No docs";
    print("$pod_text\n");
}

__END__
[download]

E.g. call:

psdoc.pl HTTP::Response base
DESCRIPTION
    $r->base
        Returns the base URI for this response. The return value will 
+be a
        reference to a URI object.

        The base URI is obtained from one the following sources (in pr
+iority
        order):
[download]

(actually, that one triggers a bug where =item pod isn't treated properly, but I'll fix that :)

Obviously it won't work for everything since not all module POD are structured in a way that makes it possible to find it. but if the sub/method name is mentioned in a =head or =item line it should work most of the time.

For your own code it could work flawlessly, since you can be diciplined and document things properly (especially if you can see the obvious benefit). Here's an example:

psdoc.pl Devel::CoverX::Covered::Db test_files_covering
METHODS
  test_files_covering($source_file_name, [$sub]) : @test_file_names
    Return list of test files that cover any line in $source_file_name
+. Or
    if $sub is passed, limit to test files covering that sub.
[download]

To be fair, I don't use this hugely often myself. For a project code base I find that I usually need to go to the method anyway in order to make sure I know enough to call it. And for CPAN modules it's usually beneficial to read the whole thing and to make sure I'm not missing something.

But I hope you'll find it useful.

/J

Realizing this feature might lead to a powerful alternative for docstrings...

... such that one may implement something like introspection - the documentation for a sub may pop up in the editor on selection...