The way this is usually done is to provide a link to the superclass documentation. I suppose one could use this link as a kind of an include statement in your postprocessing to pull in sections from the other perldocs (after you have parsed them), but as you say, it seems a bit inelegant. I would stick with the hypertext links; they are much easier to code and most people are fine with using links..
| [reply] |
It might be worth looking at Mark Overmeer's OODoc - I've not used it myself, but I seem to remember it does what you want.
| [reply] |
Thanks to chickenman
, my faith in javascript has been restored Thank you Chickenman!! :-)
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
I'd agree with kvale; the standard solution to this problem is to cross-reference the appropriate sections of the other documents with L<...> tags.
If you do want to build a summary POD that includes information from other sources, I think you'll need a pre-processing step with a separate script or template to build it.
I would suggest approaching this by writing your documentation as a template using one of the existing templating tools, like Template::Toolkit or my own Text::MicroMason. The template can include the local POD content and template directives to grep out the relevant bits of the other source files. | [reply] |
I actually had the same idea in 2001 (I just looked at the file dates), and I wrote a Pod::Class::Flattened which never left my computer. I was somewhat of a n00b at the time and I don't think it was very solid, but it worked for my problem at that time.
If you /msg me I can let you have the source. I probably won't be able to answer questions about it in any coherent way though :)
/J
Update:
This idea with the inherited api documentation is great BTW, I got inspired by reading Bertrand Meyer's Eiffel book.
| [reply] |
One feature (IMHO) that would be a real treat
to have in perl is something similar to
Python Docstrings.
Even though this is not a feature of perl, you may be able to get some ideas for modularizing your documentation by seeing how they do it in python-land. "Borrowing" conventions from them may be a way to gain some ideas. Just my 2 cents.
| [reply] |