On Wed, Feb 21, 2001 at 05:29:20PM -0500, [EMAIL PROTECTED] wrote:
> On Wed, Feb 21, 2001 at 04:39:59PM -0500, barries wrote:
> > Had a chance to look over SelfTest's POD yet?
>
> I'm looking at it right now...
Cool, thanks for the feedback.
> there might be less caveats involved if
> instead of running the module directly, you use a simple wrapper
> program:
>
> selftest lib/Some/Module.pm
>
> Filter then isn't required
I've got a nice (IMHO) command line API that allows testing of module by
package name or file name, including shell-stype wildcards and using a
"~" prefix to skip some modules. If I get time I'll convert that to use
Pod::Tests. I like the external idea better, but I thought it would be
fun to use Filter for this and see how it played. I still think it's
cool, but it's just not the right way to go.
On that note, I think it would be cool if you made the guts of of
pod2test into a method of Pod::Tests, allowing others to reuse it
without having to maul it like I did. I personally would like to see
something like Pod::Tests->as_string that could be evaled or printed.
As far as caveats, I plan on getting rid of the main one by executing
the tests in C<package main ;>. I can even eval them in a very clean
lexical environment while I'm at it.
> (why is Filter required... just to read the test POD?
It made the implementation of SelfTest trivial: about 120 lines of code
that mostly just throws away everything not =for testing. I like the
semantic that self testing is a special mode of running the file through
perl, just like perl -cw lib/Foo.pm is.
It's also probably faster than loading Pod::Tests and having it re-open
the source module, though, again, I'm not sure speed counts here.
I can do without it, of course, I'm just thinking about which way I
should go.
If Pod::Tests had a push style interface 'twould be extremely trivial.
> You could just find the module filename in %INC and feed it
> to Pod::Tests)
(caller())[1] gives it to me, luckily enough.
> and neither is loading SelfTest and all the caveats and
> extra code involved there.
Hmmm, what caveats about loading SelfTest? And SelfTest.pm could be
made quite minimal and exiting after a single call to caller() and if/ne
in the "normal" case:
$VERSION=0.01 ;
use strict ;
sub import {
my @c = caller ;
return if (
$0 ne $c[1] ## Our caller must be being run directly
|| $0 eq "-e" ## Can't scan -e scripts for tests!
|| (
( grep( $_ eq "-noauto", @_ )
|| $c[0] eq "main" ## Scripts are -noauto by default
|| ( defined $ENV{PERL_SELF_TEST} && ! $ENV{PERL_SELF_TEST} )
)
&& ! $ENV{PERL_SELF_TEST}
)
) ;
insert_filter(
line_number => $c[2] + 1,
@_[1..$#_]
) ;
}
.
> And the somewhat odd concept of running a
> module also disappears. All you need is Pod::Tests and the selftest
> program.
>
> And =alsofor (or =also for) has all sorts of problems, I don't think
> it will work. Most existing POD readers and formatters choke on it. :(
=for example
is actually worse from a backwards compatibility point of view: it fails
silently: most existing POD readers throw =for example content away. It
also perturbs the simple logic of =got and =begin/=end, whereas =alsofor
is an addition that doesn't alter existing semantics, which I think is
cleaner. I think of silent damage as being worse than noisy failure,
from the POD author's point of view.
- Barrie
