[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