On Mon, Dec 10, 2001 at 07:29:35PM -0700, Sean M. Burke wrote:
> and from what I came up with, I think it wouldn't be too hard to abstract
> this pod2xml business into two bits: one that does all the tokenization
> work and then all the things like L<...> parsing, E<...> resolution, =item
> typing, etc. and then fires events, which some other module would then turn
> into XML, either via subclassing, or via callbacks.
Hmmn - if one replaces "xml" with something suitably general purpose, the above sounds
like precisely what Pod::Parser was intended to do (but I wish I had named it
Pod::Lexer or Pod::Tokenizer instead, since people expected more than 'tokenizing'
from something named a 'parser')
The methods-to-override in Pod::Parser were intended to be pretty much the equivalent
of callbacks - with some "default" settings/interfaces for the common-case of
stream-based parsing, but allowing them to be used as general callbacks to build up
any kind of desired structure (stream-based, tree-based, or anything else).
It is admittedly over abstracted because its first practical
use was for more than just translation to some other
markup-language. I had three related tasks I needed/wanted
to do at the time:
- easily extract PODs embedded in other language comments besides
Perl (most notably shell, and some app configuration files)
so that they too would be self-documenting
- create and embed an extended pod-like language (but with more
semantics) inside one of those app-config files so I could auto-
generate not just docs, but other app-settings as well, including
some stuff based on an analysis of the contents, but without doing
any kind of formatting
- use the PODs in my own scripts to print help/usage messages
(without having to reinvent pod2text all over again - just
add some stuff to the existing one)
This is what gave birth to Pod::Parser, Pod::Select, and Pod::Usage. The first two are
probably more than most have needed to do with PODs, and are largely responsible for
why many think the design is overly complex (because its original scope was larger
than most think they want, even though it readily solved some very real problems for
me (and quite nicely too)).
I still have need for the Pod::Select and Pod::Usage functionality, but I no longer
maintain/support the installation of the other apps for the first two items above. So
if perl-porters wants to surgically remove or "extricate" additional
functionality/extensibility of the current design, then have at it. But it was there
for a real and practical purpose to solve a real problem (as opposed to just some
personal sense of speculative whimsy ;-). Otherwise, I don't see why Pod::Parser or
some straightforward subclass of it couldn't fulfill the purpose described above.
--
Brad Appleton <[EMAIL PROTECTED]> http://www.bradapp.net/
"And miles to go before I sleep." -- Robert Frost
