Re: (How) Do you document/test your private subroutines?

Concerning documentation:

I once ran into the need to document my private methods and just included "inofficial" POD.

The trick is to generate a Module.pod file for the "official" pod by filtering the Module.pm.

Running "perldoc Module" will only show the .pod if present, and that's what CPAN shows.

But running "perldoc PATH/Module.pm" will show the privat parts.

I just included this filter into my tests, like this the .pod was always up to date after running prove.

Parsing POD is straightforward, how to select the official part is up to you.

HTH! :)

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice}

Comment on Re: (How) Do you document/test your private subroutines?

Replies are listed 'Best First'.
Re^2: (How) Do you document/test your private subroutines? by stevieb (Canon) on Nov 06, 2018 at 23:52 UTC
This is a very interesting approach LanX, could you elaborate on the specifics on how you do/did this (ie. filter the pieces public/private)? Thanks, -stevieb	[reply]
Re^3: (How) Do you document/test your private subroutines? by LanX (Saint) on Nov 07, 2018 at 00:54 UTC
Um ... it's been some time and I never "perfected" the hack. :) Have a look here https://github.com/LanX/Macro/tree/master/lib Macro.pod.tpl has a template (read hack) podbuilder.pl reads the template and Macro.pm and creates Macro.pod and README.pod update As you see it's a primitive pod parser which `grab`s some parts between =head directives till =cut. you could just filter out any underscored `_private` headline or use a `=head1 Internal` to mark them. (not sure why it's missing in the git-hub version) Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply] [d/l] [select]
Re^3: (How) Do you document/test your private subroutines? by haukex (Archbishop) on Nov 07, 2018 at 20:43 UTC
One possibility: `=pod =for comment Foo! Or: =begin comment Bar! =end comment =cut` [download] I also seem to have a dim memory of someone suggesting `=begin internal` for marking things that are actually still documentation, but internal docs, but I'm not sure when/where that was.	[reply] [d/l] [select]

update