(podmaster speaks) Re: Thoughts on pod.

[PodMaster]

First I want to emphasize that pod is plain old documentation, so no changes are welcome and will be systematically rejected (yours particularly and by ten orders of magnitude).

I love pod, and I will fight with all my might to keep pod the way pod is because pod is great. What you do with pod, and how you choose to manipulate pod, should never affect pod itself, as perl views it.

CVS ~ is just that, Concurrent Versions System, and perl it self shall not be CVS, nor shall it be altered to do magical dynamic pod.

As for pod maintenance, well, you will run into the same issue even if you have some magical software do programmatic changes to the pod, you still gotta write it ... basic documentation trap

perldoc may potentially only be modified to support such a wild feature only through the use of a non-standard switch, such as -magic, as to not interfere with the perldoc we've al known so far. Stability is key.

What you speak of (reusing and "dynamic" pod) can be easily accomplished. One can use Pod::Tree, and perhaps you ought to do just that, write a module that when fed a source file would do just what you want it to do, as perl shall never indulge such a wild, but interesting, idea.

If you ever decide to implement this, I would like to play with it, so please share if you do.

As of now, the term "Dynamic Pod" is trademarked by podmaster, and can be freely and widely used as long as podmaster is the only one making money.

These have been my views on perl pod, and should be highly regarded (i'm not smiling).
 

Look ma', I'm on CPAN.

---

** The Third rule of perl club is a statement of fact: pod is sexy.

[ehdonhon]

Thank you for your input, I think you have a couple valid points nestled in there.

What you do with pod, and how you choose to manipulate pod, should never affect pod itself, as perl views it.


Good point. I agree that whatever changes occur, they should only suppliment the present system, not alter it. Also, any new additions should not break systems that correctly use present standards.

As for pod maintenance, well, you will run into the same issue even if you have some magical software do programmatic changes to the pod, you still gotta write it ... basic documentation trap


Well.. I agree. You do still have to write it. But writing pod and maintenance of pod are not the same thing. It is easy to remember to write pod as you are creating something new. Remembering all the places you need to update your pod when you make a change 9 months later is harder. While self-updating pod doesn't remove the responsibility of checking the pod from the programmer, it does make it more difficult for something to be missed.

Perhaps you ought to do just that, write a module that when fed a source file would do just what you want it to do


Good point. I suppose the best way to go about making changes is to provide a proof of concept and let people kick the tires around before proposing it as a standard.