Perl's not the only TAP source

David E. Wheeler david at kineticode.com
Wed Jun 10 19:37:34 GMT 2009


On Jun 10, 2009, at 12:19 PM, David E. Wheeler wrote:

>> 4. think of ways we can make any of this easier for people.
>
> It needs more documentation. It took me quite a while to figure out  
> that I could get at source-specific configuration data in `$args- 
> >{config}`. Data::Dumper helped me out here. I'll likely write up  
> detailed docs as I figure how how to write a proper pgTAP source.

Reflecting on this, and realizing that the vast majority of sources  
will want to execute a program, the easiest way to create sources  
would be to require that source authors implement just two functions:

1. can_handle()
2. command()

The former is the same as in source (though with one argument instead  
of three), and the second just puts together the command to be  
executed. With something like this, it'd be easy to write a PHP source  
like this:


     package TAP::Parser::Source::PHP;

     use strict;
     our $VERSION = '3.18';

     sub can_handle {
         my $meta = shift;
         return 0 unless $meta->{is_file};
         return 1 if     $meta->{file}{lc_ext} eq '.php';
         return 0;
     }

     sub command {
         my $params = shift;
         return [ 'php', $params->{file}{name} @{ $params->{config} ||  
[] }];
     }

Note how there is no registration to be made; the `sources` parameter  
in Build.PL tells it to load. The source class (or perhaps an exec  
subclass) then loads this module and calls the two functions as  
appropriate, passing in the appropriate data. That's it. This will  
make it as easy as possible for source authors to write sources: all  
they have to do is implement the above two functions and document the  
configuration keys they support (such as "dbname" and "username" in  
the pgTAP example).

This also eliminates all of the subclassing stuff that the current  
implementation requires. Just trying to make it as simple as humanly  
possible.

Thoughts?

Best,

David


More information about the tapx-dev mailing list