in reply to Thoughts on pod.

Hi.

While I havent read your post in detail (will later,) it struck a chord with me because I have been doing some interesting work with POD lately.

The basic scenario was that we have a variety of applications with fairly complicated command line and configuration components. The problem is these tools are hard to hand over to production teams due to their cryptic nature. The solution we started looking at was self documenting config files. So over a weekend with no cash I threw together the following:

Ultimately all of these will be wrapped in a module Config::Pod which will supply all configuration and command line parsing and validation. Since the config file _is_ pos then pod2html (in module form or cmd line form) can be used to generate pretty HTML versions of the config files, as well POD::usage can be used to display the rules.

When I get it all completed I plan to release it here then if its thought to be usefull to CPAN.

BTW more related to your post, have a look at the =for directive and the =begin =end directives. Using these and a POD::Parser subclass you could accomplish most of what you are interested in.

UPDATE

A clarification. ehdonhon /msgd me with a comment suggesting that I wasnt clear enough. What i meant by the above was in regard to ehdonhons idea of embedded values in pod. Specifically
then your code will be modified to include the present revision number of your code, like this: $Revision: 1.3. I wonder how easily such a system could be embedded into pod?
My point with for directive is this (and Ive basically done something similer in my code)

=for config VERSION =cut our $VERSION=0.1; =for config END_VERSION
The for directive tells the preprocessor that the following chunk of code should serve a double purpose, code _and_ documentation. The subtleties involved are left as an exercise for the preprocessor author.

Yves / DeMerphq
--
When to use Prototypes?