Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I agree that is a much more convenient syntax than =item *, but I'm getting a bit concerned about having multiple different POD dialects around, like PseudoPod [cpan.org], SPOD5 [cpan.org] (not a separate POD syntax as such though), forthcoming Perl 6 POD [perl.org] (any news on it, anyone?), pod2pdf [jonallen.info] and so on.

    Surely a =version command should be introduced so that POD parsers can reliably tell if they can process the document? I discussed this with Allison Randal [perl.org] at YAPC::Europe, and apparently the plan is to allow POD documents to specify extra modular pieces of functionality or syntax that they use, which is an interesting approach. (Seems a bit like 'roles' for POD.)

    • My approach to this with Pod::WikiDoc [cpan.org] was to explicitly define a Pod format to write in then and pre-process that format into a "canonical" .pod file that is distributed with my modules.

      See my Pod::WikiDoc lightning talk [dagolden.com] for examples.

    • Enforcing use of an =ezpod tag would be easy. I don't mind doing that.

      I probably should have waited for a definitive format, but since it doesn't break anything if you don't pre-process it I didn't see it as a huge issue, and I needed this now.

      (FWIW I modelled the design after Spod5 - but mine allows multiple levels).
    • BTW: There's no new "syntax" in PseudoPod - it seems to me that it behaves like any decent Pod parser should (well, it parses Pod in exactly the same way Pod::SAX does). Not sure why O'Reilly needed to write a new parser for it. Could have done all that with a couple of Pod::SAX plugins.