On Thu, Sep 14, 2000 at 12:15:28PM -0700, Glenn Linderman wrote:
> 1) why extract it if it could potentially be used in place
> 2) if it cannot be used in place, then why bundle it
>
> So I guess RFC 183 leaves me not understanding its goals. If there
> is a benefit to the bundling, then RFC 183 would seem to be only
> half the solution, the other half would be to use it in place.
The benefit to allowing inline tests is stated in the RFC. The main
reason why I want to extract the tests into a .t file is because then
it can benefit from the testing system already in place and that
everyone's familiar with (for limited values of everyone) and we know
works. Otherwise we'd have to completely rebuild the testing system,
and I don't really see any good reason for that. It does its job well
and its one less piece of magic to worry about.
It also means it will work in Perl 5. Very important, since I don't
want to wait two years before I can start using this. Even if we do
manage to do it purely as Perl 5, it will still require that certain
modules and utilities are installed in order for the tests to be
extracted and run. When I distribute my program, I do not want to
guarantee that the user has these incidental files (since they have
nothing to do with the running of the module itself, and users have
little enough tolerance for downloading additional modules as it is).
So I can simply run pod2tests over my code, extract the .t files and
distribute them directly.
Also, because embedded tests are ment to supplement, *not* supplant,
traditional tests, if you're going to have .t files around anyway, one
more isn't going to hurt.
> Nothing you've said below makes me think that it would be impossible
> to use the data in-place, given a unification of the concepts in
> RFCs 186, 183, and 79. Whether or not it is valuable is another
> issue, but, in the never-ending quest to eliminate redundancy, I'll
> claim that if it is valuable to embed the content in the first place
> (the point of RFC 183), then it would be valuable to use it in-place
> rather than extracting it.
Now, there's no reason pod2tests couldn't have an "inplace" switch
which would do what you propose, either by keeping them entirely in
memory or by cleaning up after itself afterwards. I've been thinking
largely for the case of testing modules, which already have a testing
harness around them. You're probably thinking of individual programs.
$ pod2tests --inplace foo.pl
foo.pl.............ok
Something like that would make sense.
Eliminating redundancy is one thing, eliminating TMTOWTDI is another.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
