[BioPerl] Re: [Bioperl-l] gff_string on an HSPI object is not Bio::DB::GFF friendly

[Jason Stajich]

Feel free to fix -
(it is probably using a default method in one of its parents, I'm not
really sure.

Personally I never really expected to use HSP->gff_string because there is
2 separate pieces of information below there and you will want
each one in different contexts so HSP->gff_string doesn't make a lot of
sense to me in the first place.

My view is that all the Search objects should be data containers and it is
up to the user to determine how to use them rather than pre-packaging too
much on the data object level.  This design goal has sort of gotten shot
as lost of people want to put convience functions on them so I guess this
would just be another example of that.

Most of the objects are already too heavy and object creation is the cause
of such slow parsing speed in the first place.  I really want to flatten
the out and reduce the inheritance levels to gain a little more speed (we
spend a great deal of time in _rearrange and walking up the SUPER -> ISA
hierarchy on each object create).


-jason

On Fri, 9 Jan 2004, Mark Wilkinson wrote:

> On Fri, 2004-01-09 at 09:38, Jason Stajich wrote:
>
> > So when you call $hsp->gff_string you are calling $hsp->query->gff_string.
>
> not really.  If that were true, then the result of calling
> $hsp->query->gff_string would be the same as calling $hsp->gff_string...
> but the are not:
>
> DB<17> p $hsp->query->gff_string
> a101 BLASTN similarity 138 160 23 + 0 Bits "46.1";FracId 1;signif
> "0.064"
>
> DB<18> p $hsp->gff_string
> a101 BLASTN similarity 138 160 23 + 0 Target gi|12329259 125209 125231
>
> that was what I meant when I said that the individual sub-features are
> not aware of each other...
>
> I'll look at your search2gff code to see how you dealt with it; I'd much
> rather see this implemented as a function than a standalone script,
> since the latter isn't very portable.
>
> M
>
>

--
Jason Stajich
Duke University
jason at cgt.mc.duke.edu