Re: Cross-referencing RFC 186 with RFC 183 and RFC 79
[email protected] (Glenn Linderman) Thu, 14 Sep 2000 00:01:03 -0700
| Newsgroups | perl.perl6.language.io |
|---|---|
| Organization | Glenn and Elaine Linderman, at home |
| Message-ID | <[email protected]> |
Michael G Schwern wrote: > On Wed, Sep 13, 2000 at 11:21:25PM -0700, Glenn Linderman wrote: > (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. > > 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. Correct. > 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. Yes. > 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? Nicer to avoid them. One problem with extracted test files is they look like source and someone might edit them, only to get them zapped later, and not get the edits included in the next revision of source. And if you have to extract them to use them, why bundle them in the first place. > 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). But unless it is the file that drives the test execution (you tell me) then it must be a file used by the test? If it is, indeed, a file used by the test, then it could be available to the test via an additional handle like today's DATA handle. Presto, .t file gone! Yes, or no... you tell me. I just want to make sure you didn't miss that aspect of this unification idea. I clearly can't go any further with the idea on my own due to lack of knowledge of the relevant pieces. > There's no compelling reason to muddle the perl core with test > switches, it can be done easier as a module. No reason unless the suggested unifications make sense. The switch would be generalized across the perl, pod extractor, and test environments, however, not be unique to tests. The tests could include a final "BEGIN" block that launches the tests at their entry point rather than at the tested code's entry point, and that wouldn't be included unless the test code was compiled. So the switch would just select which pod sections to extract on the first pass through. > > > -- > > Michael G Schwern http://www.pobox.com/~schwern/ [email protected] > Just Another Stupid Consultant Perl6 Kwalitee Ashuranse > BOFH excuse #39: > > terrorist activities -- 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 ___________________________________________________________