On Wed, Sep 13, 2000 at 11:21:25PM -0700, Glenn Linderman wrote:
> This RFC also seems to be related to RFC 183... using POD for testing. Now
> the model of use apparently envisioned for RFC 183 is to have the tests
> inside the POD, and then use a preprocessor to hack them out and put them in
> separate files. Wouldn't it be better to skip that step? Just use the "pod
> helper command line option" mentioned in the above paragraph, or a
> variation, to cause perl's first pass to (1) obtain the source for the
> program or module, (2) also obtain the source for the test module, (3)
> obtain one or more data handles for test input data and validation data, (4)
> compile 1&2 as perl source code, and (5) launch the tests, which can then
> used the appropriate data handles. But when compiled normally (without the
> test switches), all the test files simply don't get included.
RFC 79 would only effect how the tests are extracted from the code.
No alteration of the proposed syntax would be necessary,
"=for/=begin/=end testing" will still work fine.
As for adding the test extraction to the core as a command switch, I
think that's unnecessary. Extracting the testing source is trivial,
with or without RFC 79. Once extracted, a module can deal with it
just as easily, and with much more flexibility, than a core patch to
perl can. Besides, .t files aren't going anywhere and we'll still
need external (ie. MakeMaker) support to deal with them.
There's no compelling reason to muddle the perl core with test
switches, it can be done easier as a module.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
BOFH excuse #39:
terrorist activities
