Test::Harness features

[Nicholas Clark]

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.

Nicholas Clark