Thu, 14 Dec 2000 11:53:36 -0800 (PST)
On Thu, 14 Dec 2000, Fiers, M.W.E.J. wrote:
> >Hmm. Not sure why we need the Computation object for this. GeneStructure
> >already implements this.
> Yes, I agree, but computation.pm can, without adaption, store more types;
> for example if you would like to store Acceptor/Donor site location,
> transcriptions factor binding site's or whatever.
> And another pre to using the computation object in my view is that you do
> not have to know what is in there, you can get an array from the object
> containing the names of the stored subfeature types.
> Genestructure is, on the other side, more sophisticated than Computation
> because it can return a cds. In my opinion, the genestructure object could
> inherit from computation?
I can't see computation.pm or GeneStructureI (is this on a different
branch) so not sure if this applies, but rather than inheritance shouldn't
it be something like
GeneStructureI --------------------->[n] ComputationI
in our (BDGP) objects we would have this implemented by the gene's exons
and transcripts returning the result span (hsps) has as evidence
> >Remember what Ewan said? The ones with the working code win. There is no
> >such thing as someone rejecting a module (provided it works :)
> Actually i didn't remember, but I would like to see a consensus, and if the
> bioperl community does not think that it is a valuable addition, I will
> remove it.
> Concerning Ewan's remarks of producing an interface, I could agree, it won't
> be a problem to rewrite.
> Bioperl-l mailing list