On Tue, Nov 30, 2004 at 10:55:47PM +0100, Tels wrote: > > Ok, Test::Legacy it is. Now I have to figure out if I want to reimplement > > Test.pm from scratch or try and wedge a TB object into the existing code. > > Sean's added a lot of code since last I looked. > > I really have to ask :o) > > * Why rewrite? Will existing code that uses Test.pm be suddenly much better? > (I doubt this, because it seems to work. Never fix what ain't borked). Or > will Test.pm be suddenly much better? (I thought we have > Test::Simple/Test::More for that - don't like Test? Upgrade!) Or will > maintainance on Test.pm much easier? (Again, wasn't that the point behind > Test::Simple and friends?)
Dunno yet. Depends on just how compatible I want to be. A lot of the complexity seems to be in the new diff diagnostics which I might not bother with. I wrote up a very short prototype module to implement ok() a while ago, can't find it now though, just using existing Test::Builder methods. Its also not yet clear how hard it will be to get a TB object in there. Test.pm is less disciplined about where/how it does its printing than Test::More. And then there's the issue of just how Test::Builder-ified I want to make Test.pm. Getting its plan() to play nice and ok() function to go through Test::Builder is one thing. But what about getting it to obey the various output() methods? Diagnostic redirections? And all the other TB customization methods. Finally, if I don't rewrite I'm maintaining, effectively, a patch to the Test.pm source code. A patch that will have to be rewritten and reapplied for each Test.pm release. Its probably easier to implement new Test.pm functionality than integrate it at the source code level. There is an intriguing possibility. Patch Test.pm itself so that it can use TB if TB is available. This handily avoids a code fork but the trick is avoiding doubling Sean's maintenance load. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ MERV GRIFFIN!
