On Mon, Nov 11, 2002 at 09:05:13AM -0800, chromatic wrote:
> > Also, for those who aren't happy with the fact that Test::Builder is a hard
> > singleton with its state held in a bunch of file-scoped lexicals (hard to
> > debug) reset() made me collect together all those state variables in one
> > point in the source making it much easier someone to convert them into
> > object data, if they feel so inclined. I'm not yet convinced its a good
> > idea.
>
> We *could* add a method called really_create_a_new_builder() that doesn't have
> the singleton properties, but what problem does that solve? As long as we're
> stuck with test numbers, we have to try not to confuse Test::Harness.
Little known fact: test numbers are optional.
I know people have grumbled before about there being no way around the
singleton property, I just can't remember why. I'm doing that a lot lately.
Maybe I should check my hospital receipt, make sure all they took out was my
appendix. What's this scar on the back of my head...?
Ok, here's one from me.
It would make Test::Builder easier to test itself for one. There's lots of
T::B tests which deliberately throw it off into some bizarre state or cause
lots of failures. These results must be pipped off somewhere and analyzed
seperately. For those tests, we're back to using a hand-rolled ok()
function.
With two T::B objects, we could beat on one object while leaving another in
a normal state to perform the tests.
The real reason why I put all the data into lexicals rather than a hash is
because its easier to type $Have_Plan than $self->{Have_Plan}.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
11. Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.
-- RFC 1925
