Ovid wrote:
>> Side note: those features I really want control over in
>> Test::Harness
>> are the plan() and ok() methods. There's no clean way for me to do
>> that. Just look at the constructor:
>>
>> my $Test = Test::Builder->new;
>> sub new {
>> my($class) = shift;
>> $Test ||= $class->create;
>> return $Test;
>> }
>>
>> The class name is hard-coded in there.
>
> Note to self: don't post while hung over from the London Perl
> Workshop. What I just said is rather confusing. What I *need* is a
> way to easily replace Test::Builder with an appropriate subclass. I
> think I can replace the builder() method in Test::Builder::Module:
>
> sub builder {
> return Test::Builder->new;
> }
>
> But it would still be nice to have something a bit more subtle than a
> sledgehammer:
>
> sub Test::Builder::Module::builder { ... }
On the surface, this could be solved with a simple way to replace the
Test::Builder class with your own. However, I am always hesitant to do that
because of the inevitable clash.
Test::Builder is a singleton, this way custom testing modules can make their
changes in concert and with global effect. Now what happens if Test::Foo and
Test::Bar are used together in the same program? And Test::Foo decides it
wants to replace the singleton with Test::Builder::Foo and Test::Bar decides
it wants to do Test::Builder::Bar. One has to win and one has to lose. This
is not the Test::Builder way.
Somehow, multiple modules have to be able to override Test::Builder behaviors.
Yes, there are certain features which inherently clash, but that's at the
higher feature level rather than at the code level.
Something I'm considering to resolve this is the Class::C3 method plugin
mechanism, or something like it. I've used it while working on the Class::DBI
compatibility wrapper around DBIx::Class and I'm very impressed with the
amount of flexibility it allows. It also allows you to slice up functionality
by feature and combine them together.
Traits and mixins offer similar functionality. They're also a fair sight
easier to implement, considering the dependency issues Test::Builder will have
to contend with. mixin.pm is small enough that I can just ship a copy with
Test::Builder.
Finally, there's the idea of splitting up Test::Builder into an aggregate of
many objects. The aggregate itself would not be a singleton, allowing local
customization, but some of its parts (such as the part responsible for the
counter) would. I believe this is how chromatic did the Perl 6 version which
I haven't gotten around to studying.
So... it's complicated.
--
Robrt: People can't win
Schwern: No, but they can riot after the game.
