Test::Harness features

[Steve Purkis]

On 9 Jun 2009, at 22:47, Nicholas Clark <nick at ccl4.org> wrote:

> On Tue, Jun 09, 2009 at 10:14:24PM +0100, Steve Purkis wrote:
>
>> Start with extending TAP::Harness.  From what I can tell from your  
>> use
>> cases, my conversations with David Wheeler, and my own experience, we
>> have two main use cases to cater for in a plugin system:
>>
>> 1. Custom formatting (Archive, HTML, JSON, File, etc.)
>> 2. Custom sources (Archive, db, File, Nested TAP?, PHP, etc.)
>>
>> For anything more complicated, I think we could safely say 'sub-class
>> TAP::Harness for $really_cool_feature'.  Does that make sense?
>
> I think I've got the right term here - that doesn't compose.
>
> If  module 1 is on CPAN does cool feature A by subclassing  
> TAP::Harness
> and module 2 is on CPAN does cool feature B by subclassing  
> TAP::Harness
>
> then how do I get cool features A and B?
>
> I'm not sure what the solution to that is, apart from "make it  
> pluggable",
> and solving that for all possible future use cases is impossible,  
> and likely
> to make it rather slow. So I don't think I have an answer, just a  
> niggle
> that subclassing isn't a panacea.

Well, I can see what you mean on the sub-classing point.  But part of  
me doesn't think it matters - the key is our decision in what's  
pluggable.

At the mo, we've identified 'inputs' (sources) and  
'outputs' (formatters).

So the question is: should we stick to those, or should we go for more  
generic plugins?

-Steve