[Bioperl-l] Computation.pm

Hilmar Lapp lapp@gnf.org
Wed, 13 Dec 2000 20:29:59 -0800

"Fiers, M.W.E.J." wrote:
> Hi Hilmar,
> I have seen the Bio::Tools::Analysis object and thought it to be a class
> which the parsers inherit (as you say) and not so much a class to actually
> contain the results of the computation. But correct me if I am wrong.

As I already said, this is indeed the difference.

> The computation object has the advantage that it can store more complex sets
> of results. You can, for example, store a set of exons and introns and
> retrieve them separatly.

Hmm. Not sure why we need the Computation object for this. GeneStructure
already implements this.

> There are also advantages to having all computation results inheriting from
> the same class, it will make parsing of the objects much more
> straigthforward. A large advantage when producing, for example, game output,
> and there is a lot of standard information related to analysis results.

I don't see so much why it should ease parsing, because I guess you have to
get the information out of your data source anyway (the Computation class
doesn't parse, it only stores, right?). But I agree with you that there are
advantages if every object obtained from a computation is guaranteed to
implement a certain interface pertaining to computation-specific

> If you do not accept the computation object, it might be an option to merge

Remember what Ewan said? The ones with the working code win. There is no
such thing as someone rejecting a module (provided it works :)

I was trying to get a picture of how and where this fits into the Bioperl
framework, and I wanted to solicit people's feedback to the points I
brought up.

> I haven't had a change to take an in depth look at the Analysisresult

I don't think that solves any of your problems, as you correctly realized.

Hilmar Lapp                            email: lapp@gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757