[Bioperl-l] Re: Bio::Tools::Phylo::PAML::Codeml

Jason Stajich jason@cgt.mc.duke.edu
Wed, 19 Jun 2002 12:40:25 -0400 (EDT)


On Wed, 19 Jun 2002, Aaron J Mackey wrote:

>
> On Tue, 18 Jun 2002, Jason Stajich wrote:
>
> > <<Aaron showing that [he] does like some aspects of the OO in bioperl?>>
>
> Well, if it's there it should be used, or abused.  I'm willing to play the
> game, if it's already started ;)
>
> > I'm a little confused because I use factory and parser interchangeably at
> > times even though I shouldn't.
>
> Well if you're confused, then I'm in trouble.
>
> > Would we be able to build a single parser which can process output
> > from all the different PAML programs?  Or should we be building a
> > SeqIO/SearchIO style where each program has an associated parser but
> > they end up being part of the same factory system (there I go again)
> > called something like Bio::Tools::Phylo::PAML ?
>
> I think it's like SearchIO::fasta.pm - you have to be able to handle a few
> different flavors of output, with slightly different semantics, but
> overall you're describing the same analytical process.  So I don't think
> we need an IO system (since I don't see any O, just I in this case),
> there's only one PAML; perhaps we should rename
> Tools::Phylo::PAML::Codeml.pm to just Tools::Phylo::PAML.pm ???
>
Okay, we're treating baseml/codeml/aaml are like different
fasta34/fasta33/ssearch flavor of output which can be handled by
essentially the same regexps with a little tweaking.  I dig.

> > Are the result objects suitable usable by anything else that they
> > should be moved out of the Tools directory and into a MolEvo/Phylo
> > namespace (overkill I think)?
>
> No, I'd think they'd be PAML::Result objects (themselves
> Bio::AnalysisResultI objects).  It's not clear to me what a next_feature()
> method would return (in runmode = -2 a pairwise kind of
> Bio::SeqFeature::** could be made, I guess).
>
So this goes fine with your SYNOPSIS.

> > Additionally would all the data from the output from the different
> > programs fit nicely into a single type of Result object or will we need
> > different objects for different output b/c there are different classes of
> > data?
>
> I think the classes of data I described previously remain the same between
> baseml, codeml/codemlsites (additional codon-usage data) and yn00 (with
> yn00 having only a subset of the data classes).  We're not talking about
> evolver or mcmc or any other PAML program, at least not right now.
>
that is fine by me, I am okay with all of this so
Bio::Tools::Phylo::PAML::Codeml becomes Bio::Tools::Phylo::PAML
(implements Bio::AnalysisParserI)

it produces
Bio::Tools::Phylo::PAML::Result objects (which implements
Bio::AnalysisResultI, possibly implementing Bio::Factory::TreeFactoryI
as well)

We stick with your proposed method names in the SYNOPSIS.

Shall we get started?

> -Aaron
>

-- 
Jason Stajich
Duke University
jason at cgt.mc.duke.edu