in reply to Templating pod generation?

No, that won’t work. Generally, you have to generate your POD statically, else it won’t be understood by POD processors. So why not document them all once, instead of repetitively documenting each with the same boilerplate?

=head2 io( OBJ )

=head2 fm( OBJ )

=head2 cv( OBJ )

=head2 hv( OBJ )

=head2 pvlv( OBJ )

=head2 gv( OBJ )

=head2 av( OBJ )

=head2 bm( OBJ )

=head2 pvmg( OBJ )

=head2 pvnv( OBJ )

=head2 pviv( OBJ )

=head2 rv( OBJ )

=head2 nv( OBJ )

=head2 iv( OBJ )

=head2 pv( OBJ )

=head2 sv( OBJ )

Returns a boolean indicating whether OBJ is an instance of the B:: cla
+ss indicated by the method name, and respects any overridden C<-E<gt>
+isa> methods.

[download]

Granted, that’s not entirely DRY. For that, you could try turning your question on its head by parsing your own POD at load time in order to get the list of functions to generate. (I also enjoy Pod::Constants, but it doesn’t fit your use case.)

PS.: your use of eval is unnecessary:

for my $nm ( qw( io fm cv hv pvlv gv av bm pvmg pvnv pviv rv nv iv pv 
+sv ) ) {
    my $nm_pkg = "B::$nm";
    *{ $nm } = sub {
        my $op = shift @_;
        return blessed( $op ) and $op->isa( $nm_pkg );
    }
}

[download]

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^2: Templating pod generation?
by diotalevi (Canon) on Jul 19, 2006 at 06:16 UTC

    The eval means my functions have real names, not ANON in the __ANON__ package. I hadn't considered parsing my own pod to get the list of methods to generate but uh... that's possible I guess.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]

      Ah, right.

      for my $nm ( qw( io fm cv hv pvlv gv av bm pvmg pvnv pviv rv nv iv pv 
+sv ) ) {
    my $nm_pkg = "B::$nm";
    *{ $nm } = sub {
        local *__ANON__ = $nm;
        my $op = shift @_;
        return blessed( $op ) and $op->isa( $nm_pkg );
    }
}

      [download]

      As for the POD, think about it: the POD processor is just reading the file. How would it know where to look for what gets seen by the perl compiler at one stage or other when the file is compiled? (Short of solving the halting problem, anyway…) It would have to invoke the compiler on the file and then somehow hook into eval, which isn’t trivial, since CORE::eval has a variable prototype, and it certainly wouldn’t be very safe. So to cover such cases there would have to be some form of templating built into POD itself. And while it might be worthwhile to think about that, that won’t solve your problem.

      Makeshifts last the longest.

[reply]
[d/l]

        This is a runtime cost at best, the information can't be viewed statically and I think there was at least some griping that this uncovers a bug in some parts of the debugger (since fixed in 5.9 and maybe 5.8.8). I'll stick to my eval, thank you. That works as well as can be had in perl5 without macros or tt.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]

In Section Seekers of Perl Wisdom