An example: let's say that MyClassI.pm is an purely virtual, interface class: it specifies that classes that implement MyClassI.pm must provide the following methods: "do_foo" and "get_bar", and provides "fundamental" documentation describing these two methods.
Implementation class MyClass.pm provides methods for "do_foo" and "get_bar", but the author does not write any documentation for the methods; the "autodoc" tool dynamically writes the necessary POD. Small variation: MyClass.pm needs slightly more specific/modified documentation for "get_bar" (as only certain kinds of bar's are actually handled by this implementation); the author modifies the automatically provided POD, and somehow informs the tool not to overwrite their changes during the next "sync".
Subclass MySubClass.pm isa MyClass.pm, providing a few additional methods, and not overriding do_foo nor get_bar. The autodoc tool should "copy" MyClass.pm's method documentation into MySubClass.pm (perhaps in an =head1 Appendix). Small variant: MySubClass.pm overrides do_foo, but needs no change to the documentation: MyClass.pm documentation (which itself is MyClassI.pm documentation) gets used. Small variant #2: MySubClass.pm overrides do_foo, but now does have its own specific docs, and doesn't want to be overwritten during the next sync.
I think all the necessary tools are already in place (Pod::Constants, interface.pm, etc), but before I embarked I thought I'd bounce the design principles around here for awhile; I'd also love to be told that solution already exists!
Thanks,
-Aaron
In reply to synchronized documentation by amackey
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |