[Bioperl-l] Computation.pm

Ewan Birney birney@ebi.ac.uk
Thu, 14 Dec 2000 09:10:07 +0000 (GMT)

On Wed, 13 Dec 2000, Hilmar Lapp wrote:

> Thanks for the submission Mark. Have you checked against
> Bio::Tools::AnalysisResult? This one is supposed to be the base class for
> analysis result parsers. It's not a feature though.
> Do we really want to have all-encompassing feature objects? Could it be
> smarter to have features which can have an object attached that describes
> their computational origin?

My feeling is that we should not do this by implementation inheritance but
by interface inheritance of composition/delegation model. I would suggest 
something like this:


      enforces that the implementation has a

      ->computation call returning a

   Bio::Tools::Computation object which has parameters "program" etc (is
that what we need?)

(This is like Bio::DBLinkContainerI - object which contains an
array of DBLinks)

Then we can have *implementations* inheriet from say,

   SeqFeatureI and ComputationalResultI, indicating that this object is
both a SeqFeature and has a ComputationalResult 


  GeneStructureI and ComputationalResultI


   WeirdNewAnalysisObject and ComputationalResultI

etc etc...

What do people feel --- I really like having "lots of interfaces and fewer
implementations" --- I think it future proofs us and is good for
bioinformatics where you want to mix-and-match attributes on objects very

It also probably means I should program more in java and less in perl ;)
Oh well...

Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420