[Bioperl-l] Bio::SearchIO::hmmer hsp behaviour

[Sendu Bala]

Chris Fields wrote:
>
> Personally, I don't think right now is the time to think about refactoring
> this particular module, esp. since I find it essentially works.  I believe
> that energy is better spent elsewhere, such as SeqIO::genbank/swiss/embl for
> instance, or refactoring SearchIO::blast etc to use hashes instead of
> objects to speed things up.  Or creating something yourself.  Or doing what
> you currently are doing (Bio::Map).  In other words, areas where use is
> high, code is aging, and refactoring is more productive.

Hmmer parsing happens to be important to me, in fact vital for my work. 
I've been using my own parser up till now, so didn't know what the 
Bioperl one was like. I'd like to use Bioperl for more things, 
preferably everything.


> I'll add that I'm not trying to dissuade you from trying to build your own
> variation of a SearchIO HMMER parser; by all means go ahead.  The above is
> how I feel.  You can build your own parser to do what you want; you can even
> base it off the current SearchIO HMMER parser and see if you can set it up
> to give you the results you want, using a different handler and so on.  Just
> don't break the API or modify the current code based strictly on what your
> opinion of how it should work is.  It was probably set up this way for a
> particular reason.

Well, I don't like the idea of there being multiple SearchIO parsers for 
the same thing.

[...]
> And, frankly, it's not up to the user when using code they didn't create.
> You have to deal with it.  Or code something yourself to do things the way
> you want.  You have the power to do that; most bioperl users don't simply
> b/c they probably don't understand the class structure and OO nature of
> Bioperl.  It's just a matter of where you want to spend your energy: dealing
> with something that interests you or fixing other's people's broken code.

My original question was essentially: does doing it my way make sense? 
And implicitly: would doing it my way be of any harm? Ie. can I go ahead 
and change how the parser reports results and groups them together? I 
don't think it will involve an API change, but the results it generates 
will obviously be very different.