Marek Rouchal DAT CAD HW Tel 25849 wrote:
>
> And for hyperlinking you need two passes anyway, and thanks to Storable you
> can conveniently store the whole tree and run the second pass over it as soon
> as all hyperlink destinations have been computed. I don't want to go into the
> details, but I have certainly a lot of pros for an OO approach.
Oh, it's all OO, the issue is whether it's a tree transformation tool or an
event handling system. It's a mistake (IMHO) to foist the tree handling
architecture on programmers who want a simpler model or who face memory
constraints (witness the need for XML::Twig). I'm not arguing that the
whole-tree approach isn't more useful in some cases, just that it doesn't
fit the majority of my needs, and that forcing people to use that as a
tool is adding a performance penalty (certainly in the single-pass case)
and adding a barrier to entry in the form of an increased learning curve.
> I haven't coded Pod::Compiler into my Marek::Pod::HTML yet, but I expect a
> dramatic increase in performance when converting e.g. the whole Perl
> distribution PODs.
Cool, let us know what you find.
> There are two differing requirements here: On the one hand, we need a
> fast! parser for online viewing, on the other a base framework for complex
> converters to avoid coding the same all over again.
We agree. One possibility is that Pod::Compiler should be factored into
two components: the parser engine (perhaps migrating stuff to Pod::StdParser
or Pod::Parser), and the tree builder. The cmd_ and seq_ dispatching
I'm borrowing and extending (a bit) from Russ's Pod::Text allow easy addition
of extensions just by declaring new cmd_...() or seq_...() methods, so that
subclassing Pod::Compiler (if it becomes is-a Pod::StdParser) to create
compilers for POD superset languages should be easy, too.
It looks like all that you would need to do to inherit from Pod::StdParser
is split command() and delete a bunch of warnings. I need to add a few
more warnings to Pod::StdParser, but most are already there.
> I've included my 0.01 of Pod::Compiler and a sample script
Thanks!
> (sorry, no module package) for you to have a look at. Yes, there are a
> lot of TODOs.
Better to release early than wait until all t's dotted and i's are crossed,
as my grandaddy always used to say. Or something like that.
> I've had a brief look: Yes, it is a sensible extension of Pod::Parser, but
> it uses callbacks rather than creating a tree. The functionality of
> Pod::StdParser could quite easily be included in Pod::Compiler, IMHO.
Definitely, but Pod::Compiler's already huge. Better to factor it in two,
methinks. But you knew I'd say that ;-)
> The big question is: Could the tree-approach satisfy all requirements or
> do we need separate, highly optimized converters for every single output
> format?
If you can show significant speed gains without requiring gobs of
memory or disk space (I know I admin some systems with little spare room
to cache all those Storable objects: clients' systems where hardware upgrades
don't come easy) , no matter how it works internally (DOM, SAX, or infinite #
of monkeys hacking perl), I think people will want it.
But a simple event-driven Pod::Parser derivative is needed for simpler needs.
- Barrie
