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