[Bioperl-l] Computation.pm

[Hilmar Lapp]

Right now Bio::SeqFeature::Computation is relatively isolated
(actually, completely isolated). I wouldn't want any SeqFeature
class to directly inherit from Computation.pm, and there wasn't
much support for this route from others. The module is useful
though.

I support Ewan's proposal, which let's the SeqFeature classes
remain lean enough and still voluntarily use it.

Any comments on this, also regarding the release? Are we happy
with having it isolated in the release? If there's support for
Ewan's suggestion, anyone willing to do the implementation? Mark
F.?

I admit this is not on the task list; the reason is the module
came in far after closure of the task list. Still, the consequence
is that those assigned with tasks on the list are unavailable ...

	Hilmar

-------- Original Message --------
Subject: Re: [Bioperl-l] Computation.pm
Date: Thu, 14 Dec 2000 09:10:07 +0000 (GMT)
From: Ewan Birney <birney@ebi.ac.uk>
To: Hilmar Lapp <lapp@gnf.org>
CC: "Fiers, M.W.E.J." <M.W.E.J.Fiers@plant.wag-ur.nl>,
bioperl-l@bioperl.org

[...]
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.
[...]