Marek Rouchal DAT CAD HW Tel 25849 wrote:
>
> On Thu, 3 Aug 2000, Brad Appleton wrote:
>
> BA>Besides, I think there is still need for a Pod::Translator
> BA>of Pod::Compiler module that uses (or is subclassed from)
> BA>Pod::Parser to be the *real* base parser that people use (the
> BA>one that actually knows the commands, just not necessarily
> BA>the output format). I think putting =also in this new module
> BA>instead would be a much needed first step to making a much
> BA>more useful Pod2Xxxx base module that safely assumes it is
> BA>used exclusively for translating perlpod-compatible commands
> BA>into some output format (unlike Pod::Parser which simply parses
> BA>into commands and paragraphs and prase-trees without knowledge
> BA>of the meaning of them).
Agreed, especially if volunteers can be found to port existing Pod::Foo
converters to use this new Pod::StdParser (or whatever). I like the
way that Pod::Text does $self->cmd_foo(...) dispatch, perhaps
- moving $self->cmd_foo() dispatch to Pod::Parser,
- creating a Pod::StdParser that
- knows about well-formedness,
- implements C<=also>, and
- allows =for/=begin...=end filtering
- provides some status attributes & methods to allow context to be
queried, like if you're in an =for/=begin...=end region
- porting Pod::Text, some Pod::Html, etc., to use Pod::StdParser would be good.
Subclasses to support added commands would be able to define new members
for each command they add: =bar needs a sub cmd_bar() {}.
> 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.
> 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.
So Pod::Compiler would be a POD DOM builder?
I can see a use for POD DOM based tools, but a DOM seems a bit too complex
to require for writing basic pod2foo utils. The $self->cmd_...() callback
scheme used in Pod::Text seems simpler and easier to use to me. Less
learning curve, less & more efficient code, easy to implement
new translators and POD extensions.
> I certainly would like to volunteer for coding such modules, but I have no
> idea when there'll be time for this.
I'm not going to volunteer for a POD DOM approach, but I am volunteering
to help
- factor the $self->cmd_foo() dispatcher from Pod::Text to Pod::Parser
or (new) Pod::Dispatcher or something
- implement a Pod::StdParser that adds support for standard constructs
- filtering on =for/=begin...=end tags
- =also
- warning & errors detection
- tweak Pod::Text to be a Pod::StdParser
- perhaps write Pod::Extractor::Tests (or whatever) to do POD->test suite
extraction. This will also need some modes to MakeMaker, I think, to
extract the test suites as part of target 'pure_all' or something.
I can't jump on this for a month or so, just too busy. And, hey, RFC11
isn't even voted on yet :-). I'll revise it to reflect whatever approach
we come up with.
Other volunteers welcome! The size of this task is what motivated me to
propose hacking Pod::Parser rather than redo everything. I don't want
to see =also burdened with so much required effort that it dies.
- Barrie
