Marek Rouchal DAT CAD HW Tel 25849 <[EMAIL PROTECTED]> writes:
> I'd like to assent to this idea. While coding a new POD to HTML
> converter (MarekPodHtml-0.41) and starting with POD to MIF (FrameMaker),
> I found that much of the code is reusable.
I thought I discovered that too, with Pod::Text and Pod::Man. Then I
started fixing bugs and improving them, and the code I reused generally
got changed beyond recognition. At this point, about the only code in
common is dispatch code to resolve commands into method calls, which is
not only simple but probably replaceable by setting callbaks in
Pod::Parser using the proposed alternate interface.
> An ideal Pod::Compiler would - very much like the existing Pod::Checker
> - extract node (=head, =item, X<...>) information from a given POD that
> serve as link destinations.
This would be usful for those output formats that support links, agreed.
This is one of the few things that I can see the need for a supporting
module, but I don't agree that it's one that should be used by every POD
translator necessarily.
> A Pod::Translator would read a POD and build an object tree.
Pod::Parser already does this.
> By making use of Perl OO features the individual objects (Pod::head,
> Pod::list (with Pod::item kids), Pod::paragraph, Pod::verbatim etc.)
> would only need an appropriate "translate" method that would be filled
> with the guts of the destination format.
Pod::Parser already comes close enough to this that I think the additional
marginal utility would be pretty small and not worth the speed hit from
the extra level of method call indirection.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
