[Bioperl-l] Bio:Tools::Primer3, Bio::Seq::PrimedSeq, and Bio::SeqFeature::Primer

[Rob Edwards]

Elia and others,

I like the idea of splitting up running from parsing. At the moment Bio::Tools seems to contain a lot of parsers, and then some other things that don't really go together (notably Bio::Tools::CodonTable, Bio::Tools::SeqStats, Bio::Tools::SeqWords, Bio::Tools::Sigcleave, Bio::Tools::OddCodes, Bio::Tools::IUPAC, Bio::Tools::Gel, Bio::Tools::WWW, Bio::Tools::pSW, Bio::Tools::Alignment::Trim). Perhaps a Bio::Tools::Parse would complement a Bio::Tools::Run?

I took a look at Bio::Tools::Run::WrapperBase, and as far as I can see at the moment a lot of this is not implemented (e.g. run(), program_name(), and program_dir(). Is someone working on this, or should I spend a little time messing around with it.

How do you see this handling different input requirements? Presumably Bio::Tools::Run::WrapperBase would just pass whatever it is fed without thinking about it. Most programs require stdin to be in their own format, and few seem to be consistent (consider clustalw input versus phylip packages input versus primer3 input). I don't think that WrapperBase should handle these, rather the individual run modules should check the sanity of the input.

Rob



On Fri, Mar 21, 2003 at 03:21:26PM +0800, Elia Stupka wrote:
> Hi Robert,
> 
> Good to see Primer3 coming along, some comments:
> 
> you might want to have a look at bioperl-run. We have decided to split 
> the actual "running" of programs from their parsing, so in theory you 
> should have a Bio::Tools::Run::Primer3 that inherits from 
> Bio::Tools::Run::WrapperBase and has some standard methods such as run 
> (I notice you call the method exc, but the doc title is run...). Also 
> all the arguments can then be simply put in a begin block as arrays of 
> keyowrds which get "authorized" to be used by the OK_FIELD hash (see 
> any of the run modules in bioperl-run for more specs).
> 
> Then the parser would go into Bio::Tools::Primer3 only for the parsing 
> methods, which would be at least the basic next_result method shared by 
> other Tool parsing modules (though admittedly we haven't yet come up 
> with a proper interface module or base class)
> 
> Elia
>