[Bioperl-l] Bio::*Taxonomy* changes

Hilmar Lapp hlapp at gmx.net
Mon Jul 24 20:12:39 UTC 2006


On Jul 24, 2006, at 3:49 PM, Chris Fields wrote:

> Yes, 'largely' the key word.  I don't really agree with Sendu's  
> hierarchy
> scheme (making Species implement Taxonomy and not Node doesn't make  
> sense),
> but, besides that, everything else seems fine.  I like the  
> following setup
> (which is similar to what you proposed, I believe), which I already  
> posted.
>
>             |-----Tax::Node
> NodeI-------|
>             |-----Tax::SpeciesNode
>                 |
> SpeciesI -------|
>
> Taxonomy::Node is-a NodeI
> Taxonomy::SpeciesNode is-a NodeI and-a SpeciesI

I don't even think we would need SpeciesI - why would a species- 
ranked taxonomy node be so different from any other node such that it  
would need its own interface.

Chris - just one suggestion: take a step back and imagine a Bioperl  
in which Bio::Species had never existed. Instead, only taxonomy nodes  
existed, and code that can effectively deal with them, including  
filtering by rank. In this picture, what would you make to want to  
introduce SpeciesI and Bio::Species?

Frankly, I don't see anything. I.e., the only reason is backward  
compatibility (which is a valid reason), but let's not glorify  
Bio::Species by adding ill-conceived interfaces.


>
> Bio::DB::Taxonomy uses a factory to return NodeI-implementing modules;
> specifically, a SpeciesNode for species ranks or below, and a Node for
> anything else.

Like I said before, SpeciesNode or whatever it's called would draw  
its right of existence solely from backward compatibility - don't use  
it for anything else. And if you can achieve backward compatibility  
by other means, don't even create a SpeciesNode.

My $0.02 ...


	-hilmar
-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================








More information about the Bioperl-l mailing list