[Bioperl-l] Computation.pm

[Fiers, M.W.E.J.]

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.

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. 

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.

If you do not accept the computation object, it might be an option to merge
some of its structures to SeqFeature::Generic and others to the
AnalysisResult object, just to have somewhat more uniformity to storage?

I haven't had a change to take an in depth look at the Analysisresult
object, so maybe my arguments are false. I won't be able to read my mail
before monday, so answers could be slow.

I do agree to slim and comprehensible class sets.

Thanks, Mark





"Fiers, M.W.E.J." wrote:
> 
> Hi
> 
> I've commited a Bio::SeqFeature::Computation.pm to the cvs. It is a
> variation on the Generic.pm SeqFeature object but more geared towards
> containing the results of a computation result.
> A big goal of writing this is also to make the game export more
> straightforward.
> 
> Since I'm kind of new to this, I hope I did everything alright.
> 
> Biggest changes are
> * The subSeqFeature's are grouped into subset's. i.e.
>       $feat->add_sub_SeqFeature($subfeat,'repeat')
> * There is a data structure exactly like tag, but named score
> * It contains a computation_id (like game does)
> * Lot of items like program_name and database_version added
> 

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?

I personally tend to prefer to have classes as slim as they can be, and
rather have more classes and a more complex object tree (objects having
several other objects attached) which of course increases the traversing
complexity.

In addition I think we need to keep the number of classes in
Bio::SeqFeature as comprehensive as possible, because people using the
package will try to comprehend which class to use for what. That is, the
extent of overlap between classes should be as little as possible. In
the
case of SeqFeature::Computation this would mean that _every_ feature
object
derived from a computation shall inherit from it (rather than some do
and
some deliberately don't).

What do people feel about these aspects? Do you disagree, do you think
this
would lead us towards imposing to strict requirements on module
implementors? In other words, what degree of controlling the bazaar's
growth is sensible?

	Hilmar
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp@gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------
_______________________________________________
Bioperl-l mailing list
Bioperl-l@bioperl.org
http://bioperl.org/mailman/listinfo/bioperl-l