Making a source

[Steve Purkis]

On Jun 26, 2008, at 12:06, Andy Armstrong wrote:

> On 25 Jun 2008, at 23:59, Steve Purkis wrote:
>> Also, (slightly OT) I was thinking of going OTT and introducing a
>> SourceFactory.  This is so you could have Source::Perl,
>> Source::Python, Source::PHP, Source::YerMom, etc.  The current source
>> could move to Source::Shell (or ::Command).  I don't know how silly
>> that is, it's 7 to midnight after all, but the idea was to make it
>> really easy to extend sources.
>
>> Finally, (more OnT) I had the pleasure of realizing today that
>> there's no easy way to tell TAP::Harness about all this nifty
>> subclassing mumbo jumbo.  You have to get stuck in, and create your
>> own subclass of T::H if you want a custom Perl source.  That should
>> probably change too.
>
> Is subclassing TAP::Harness more difficult than subclassing a factory?

Not substantially, but it is something else you have to figure out  
how to do, and then something else to maintain.


> In code that we have at work I'm currently providing a custom source
> by subclassing TAP::Harness and overriding _get_parser_args.

Likewise, and it's been working well so far.  But I can see 2 ways to  
remove the need for this:

1. move to a factory model for sources and then override the default  
whatever source, ala:

   sub MyPerlSource;
   @ISA = 'TAP::Parser::Source::Perl';
   TAP::Parser::SourceFactory->register_type( 'perl' => __PACKAGE__ );

And could use prove on the cmdline:

   prove -MMyPerlSource

2. subclass source, and let the harness know about it somehow.  maybe:

   my $h = TAP::Harness->new({ perl_source_class => 'MyPerlSource' });

This is wooly.  And perhaps really annoying if TAP::Harness needs to  
know about everything TAP::Parser knows about.


> I think that before we make more interface changes I'd like to sketch
> out some use cases....
[snip]

That's a good plan.  Will reply to Eric's email.

-Steve