[Bioperl-l] Computation.pm

[Ewan Birney]

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:


   Bio::ComputationalResultI


      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 


or

  GeneStructureI and ComputationalResultI

or

   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
often.


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
<birney@ebi.ac.uk>. 
-----------------------------------------------------------------