[Bioperl-l] interoperability with bioperl
birney at ebi.ac.uk
Wed Aug 31 09:13:46 EDT 2005
Rutger Vos wrote:
> Dear BioPerlers,
> I am the author of a phylogenetics oriented package on CPAN called
> Bio::Phylo (link in my sig). The tree object is superficially similar to
> something that implements Bio::Tree::TreeI, and so I'm looking for a way
> to implement interoperability - at least for that object - with BioPerl.
> Bio::Phylo is more aimed at phylogeneticists, who might not be as
> interested in installing the BioPerl core (and sort out the dependencies
> and so on), so I am not looking to integrate in BioPerl.
> I am now leaning towards implementing interoperability in the following
> i) I create a separate CPAN package, with BioPerl & Bio::Phylo
> dependencies (so that my own "core" doesn't require bioperl).
> ii) this package inherits (using "use base" & "use fields" from
> Bio::Phylo::Trees::Tree, see
> iii) this package @ISA Bio::Tree::TreeI (see
> iv) hence, through multiple inheritance, a "hybrid" tree object is
> created, which implements both APIs (there's a fair amount of overlap, I
> might get away with just symbol table manipulation (globs) to implement
> I solicit your thoughts on whether you think this is the right way to go
> about things. My main worry is that there'll be problems if people have
> taken to sticking their fingers inside Bio::Tree::TreeI-like objects to
> fondle their attributes directly. Then again, that "voids their
> warranty", perhaps.
This is precisely the way to go and I am planning on a similar approach
to "bridge" between Ensembl and Bioperl - ie, make wrapper classes that
holds onto the Ensembl object, and delegates the necessary I defined functions
for Bioperl "Clients".
As you said, if I client starts looking inside the object directly then
its on its own head.
> Best wishes,
More information about the Bioperl-l