Michael,
Thanks for the explanation. So you see, I'm one of those people that go around
looking for redundancies to eliminate. So when I hear that you want to extract
a .t file from perl source (as specified by the RFC 183), it makes me wonder
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.
Regarding my comment about "junk" below, I didn't mean that the content was
junk, but the file, since it would (given RFC 183) become redundant with the
same content embedded in the module source, is, because it is redundant, junk.
If it had to be extracted to be used, then it should be cleaned up after it is
used, because it is redundant. If it could be used in place, then it doesn't
need to be extracted, nor does it need to be cleaned up.
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.
Michael G Schwern wrote:
> On Thu, Sep 14, 2000 at 12:01:03AM -0700, Glenn Linderman wrote:
> > > Once extracted, a module can deal with it
> > > just as easily, and with much more flexibility, than a core patch to
> > > perl can.
> >
> > Who cleans up all the junk files later?
>
> Nobody does, they're not junk. They go into the t/ directory of the
> module/code distribution. More on that later.
>
> > And if you have to extract them to use them, why bundle them in the first
> > place.
>
> Because its all done for you as part of "make test".
>
> > > Besides, .t files aren't going anywhere and we'll still
> > > need external (ie. MakeMaker) support to deal with them.
> >
> > Oh? I'm no QA guy, right? So I have no clue what a .t file is (sorry).
>
> A .t file is simply a Perl program which outputs a series of "ok" or
> "not ok" for each test run. Nothing more. They typically reside in a
> t/ directory of a module's source code (that or there's one test.pl
> file). Download any module from CPAN and have a look. A simple
> example would be:
>
> #/usr/bin/perl -w
>
> print 2+2 == 4 ? "ok 1" : "not ok 1";
> print 2*2 == 4 ? "ok 2" : "not ok 2";
>
> When you run "make test" on a module it looks for test.pl and t/*.t,
> runs them, and counts up the "ok"s and "not ok"s. Simple. Thre's no
> plans to change this AFAIK.
>
> So all RFC 183 needs changed is that when "make test" happens,
> pod2tests would be run over each source file generating a .t file from
> any embedded tests found (lib/Some/Module.pm's tests would go in
> t/Some-Module-embedded.t) and the rest is as it is now. The .t files
> are run and oks counted.
>
> Simple, with a minimum of modification to the existing system.
>
> Sorry if I took it for granted that people would understand the
> testing system. And anyone for whom the above was new information, I
> expect you FRONT AND CENTER at the "Writing Solid Perl" tutorial at
> YAPC::Europe.
>
> --
>
> Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
> Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
> MORONS!
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
