[Bioperl-l] SeqFeature/AnnotatableI and rel. 1.6
cjfields at uiuc.edu
Thu Aug 23 17:33:25 EDT 2007
So far most of FeatureIO.t passes, with only a few exceptions dealing
with the from_feature method (I know what the problem is there). A
large number of other tests crash horribly (not so surprising), so
I'll have to go through those. Ergo any changes and testing will
definitely be conducted on a branch then merged back to main trunk
once everything is okay. I'll probably start a branch in the next
few days or so.
Here's what I have been working on so far, which I think is reasonable:
1) Move all *_tag_* related methods out of Bio::AnnotatableI and into
2) Reinstate the same tag methods in Bio::SeqFeatureI and remove
Bio::AnnotatableI from the inheritance tree.
3) Make Bio::SeqFeature::Annotatable Bio::AnnotatableI (which it
already was, strangely enough). Now it simple implements the proper
methods from the interface classes SeqFeatureI and AnnotatableI.
4) Revert Bio::SeqFeature::Generic tags back to simple untyped
strings (reimplement the 1.4 rel methods).
I'm interested in seeing whether this results in a significant
performance increase in SeqIO since the Annotation instantiation is
ToDo: I plan on removing the operator overloading in Bio::Annotation,
which was a serious sticking point with most of the devs. This won't
be done until after tests pass for everything else.
What we will need at some point which I can't provide:
Bio::SeqFeature::Annotated has no docs (no synopsis, no
description). The reason I bring this up is Sendu and I are
seriously considering running an automated code audits in order to
gauge which modules lack docs, test coverage, etc.. We're likely
splitting those without adequate test/doc coverage off into a
separate 'dev' release.
On Aug 23, 2007, at 2:53 PM, Scott Cain wrote:
> Hi Chris,
> GBrowse would be unaffected by this as it doesn't use
> Bio::SeqFeature::Annotated. The GMOD GFF3 Chado loader on the other
> hand will almost certainly break horribly, as it depends on the strong
> typing of Bio::FeatureIO/Bio::SeqFeature::Annotated. If you could try
> your ideas out in a branch that I could checkout and test on, that
> be good.
> On Wed, 2007-08-22 at 23:53 -0500, Chris Fields wrote:
>> As many of the devs know, there are a number of Feature/Annotation
>> issues that need to be resolved prior to a 1.6 release:
>> There has been little work done over the last 2 1/2 years to undo or
>> rectify problems associated with those additions; I feel like those
>> of us still routinely contributing have been left holding the bag.
>> There has also been very little attempt to document any of this
>> adequately enough; as an example see POD for
>> Bio::SeqFeature::Annotated (what little there is).
>> I would like to suggest the radical idea of rolling back
>> SeqFeatureI changes to a much simpler rel. 1.4-like behavior (tags
>> are simple scalars) and possibly work in implementing Ewan's
>> SeqFeature::TypedSeqFeatureI for those who want strong data types
>> (i.e. Bio::FeatureIO/Bio::SeqFeature::Annotated). The various
>> AnnotatableI changes, odd inheritance, and operator overloading have
>> really obfuscated the code to the point where no one wants to touch
>> it in case it breaks something important. However, I believe it is
>> the one serious impediment to a new stable release.
>> My thought is we simplify all the relevant interfaces, essentially
>> reverting back to rel 1.4. For instance, we move the various
>> Bio::AnnotatableI tag methods back into Bio::SeqFeatureI.
>> Bio::SeqFeature::Annotated would implement Bio::AnnotatableI
>> directly, and (if needed) also implement
>> Bio::SeqFeature::TypedSeqFeatureI, so the impetus is on
>> Bio::SeqFeature::Annotated to overload the relevant SeqFeatureI
>> methods correctly, just as any other class would when implementing an
>> abstract interface. I have played around with this a bit and managed
>> to get most tests working again for Bio::SeqFeature::Generic and
>> FeatureIO but a number of others break.
>> If needed I can try this out on a branch (a bit ironic, since the
>> changes instigating this mess should have been tested on a branch!).
>> Maybe this will get the ball rolling towards a 1.6 release. Any
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
> Scott Cain, Ph. D.
> cain at cshl.edu
> GMOD Coordinator (http://www.gmod.org/)
> Cold Spring Harbor Laboratory
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
Lab of Dr. Robert Switzer
Dept of Biochemistry
University of Illinois Urbana-Champaign
More information about the Bioperl-l