On Fri, Mar 02, 2001 at 12:15:26AM -0500, barries wrote:
> I wanted it so SelfTest's filter handler could feed source code to
> Pod::Tests chunk by chunk and let it do the extraction.
I just put up a new version of Pod::Tests. It does the "push" style
you were talking about (you just call parse() multiple times).
However, I added an EXAMPLE which shows how to self-parse using the
DATA filehandle in one shot.
> > Anyhow, I really want to see the finding of the testing code merged.
>
> Not sure what you mean. Do you mean that you want all utilities that
> find testing code to use Pod::Tests? That would be nice, but POD, and
> the trivial subset that marks test code, is so simple I doubt all people
> will feel the need to require Pod::Tests.
The parsing wasn't hard, but I wouldn't call it trivial. Unless I
overcomplicated the problem somehow.
> > I'm not suggesting =for example.
>
> Beg pardon, I thought you were since Pod::Tests implements it.
Pod::Tests does "=also for example". It will also accept "=for
example" but that's doesn't do anything special. I could add a
warning "Saw =for example, perhaps you ment =also for example?" or
something.
> Anyway, it seems like MakeMaker's PREREQ_PM can address some of this by
> allowing module authors to require up-to-date podlators using
> Pod::Parser's version number. Then we'd just need to make sure that
> Pod::Parser and it's clients are backwards compatible with older perls.
That's an interesting possiblity. Shouldn't be too hard to convince
Brad to have Pod::Parser let unrecognized tags off with a warning
instead of dying.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
That which stirs me, stirs everything.
-- Squonk Opera, "Spoon"
