Perl's not the only TAP source
steve at purkis.ca
Sat Jun 20 16:49:54 GMT 2009
On 20 Jun 2009, at 14:21, Andy Armstrong wrote:
> On 20 Jun 2009, at 14:14, Steve Purkis wrote:
>> So the todo list:
>> 1. Get people to agree whether or not we need a generic plugin
>> As far as I can tell, there are 2 options:
>> * source & formatter plugins only (ie: source API stays the same)
>> * generic plugins (API not defined yet)
> I'm not what else there is to make pluggable apart from formatting and
> source handlers - but I'm open to suggestions.
Me neither :).
Assuming we settle on this, the next question is: should we allow the
user to supply config and auto-load formatters as we do with sources?
>> 2. Figure out what to do with TAP::Parser::Iterators.
>> I'm still not convinced we need a separate class of iterators for
>> the parser to use. Source classes could be iterators too, and that
>> would remove the need for the IteratorFactory class, which basically
>> just makes decisions the Sources could make themselves.
> Yeah, I think that's right; a source should be an iterator.
>> Of course, in your examples you seem happy to delegate the running
>> commands to the iterator classes. So maybe they should stay after
>> all? Or maybe we can just get rid of the 'Factory' class, and let
>> the source classes use the iterators directly? I know I introduced
>> it, and for valid reasons at the time. I just feel it over-
>> complicates things now.
>> Andy/Eric: It'd be good to have your thoughts here.
> Simplify! Unless we can come up with a good reason why the iterators
> are distinct from sources they should go.
Well, at the very least the IteratorFactory should go.
Thinking about it a bit more, one reason I can think of why Iterators
themselves shouldn't go is if it makes writing a Source plugin any
more difficult. Say we put all the complexity of the Process iterator
into the Executable source, won't plugin-authors that are using roles
would either be forced to sub-class, or re-implement that logic in
some way? Or am I missing something?
>> Now the bad news as for when I'll be free... I've got an exam to
>> prep for in a week and a half, so hopefully after that.
> Hmm. I wonder if I shouldn't have merged sourcedetector into master
> then. I'd like to be able to make a release of 3.18 if the need
> arises. Thoughts?
Well, it is releasable as it stands. The main thing is to avoid
setting the new API in stone, which we can easily do in the pod. I
know I've started on that ('sources' in TAP::Harness & TAP::Parser).
I've just noticed the TAP::Parser docs need updating (grep for TODO),
that's probably the only thing that would need to be updated for a
Alternatively, it can always be un-merged until we settle on the
interface & implementation.
Finally, others can always help take this forward :).
(who really should be studying :)
More information about the tapx-dev