[Bioperl-l] AnnotationCollectionI and SeqFeatureI changes

Allen Day allenday at ucla.edu
Mon Nov 29 17:30:40 EST 2004

On Mon, 29 Nov 2004, Aaron J. Mackey wrote:

> Yep, OK, I hear you.  I really thought all this was going to be 
> contained to Bio::SeqFeature::Annotated, but I see now that with all 
> sorts of implementation happening in the interfaces (ugh!), this can't 
> happen.  Woe is me.
> Here's what I'm willing to do to keep Allen from pulling his hair out: 
> there have been very few changes on the development trunk since RC1 
> that aren't Annotated.pm-related; therefore, (if this makes sense to 
> everyone) I will branch 1.5.0 off of RC1 and merge only those patches 
> that are Annotated.pm-*unrelated* to the 1.5.0 branch.  I will then tag 
> the branch at RC2 (and similarly tag the HEAD, so that any later 
> merging can be done relative to those tags).  Make sense?

yeah.  i think the easiest way to restore old functionality is going to be
to roll back SeqFeature::Generic to before i removed the current
SeqFeatureI overriding methods (get_tag_values(), add_tag_value(), etc),
or to re-add these methods.  this also necessitates rolling back
SeqFeature::AnnotationAdaptor and its unit test, as it assumes the *_tag_*
hash and the attached AC don't overlap.

that's pretty much it.  the interface classes can stay the same -- it
won't affect the "heavy" lifter (SeqFeature::Generic), and it will allow
SeqFeature::Annotated to continue to depend on the revised interface.


> Then, the rest of you (Allen, Hilmar, Steffen, etc) need to figure out 
> the cleanest path for 1.6.0, in which all things may change (with an 
> eye towards at least some backwards compatibility); my vote would be 
> that there remain some separation between "heavy" and "light" feature 
> types.  I don't expect/need my Bio::SeqFeature::Simple to implement 
> AnnotationCollection!
> Thanks again to everyone; let me know if the CVS plan above sounds 
> reasonable ...
> -Aaron
> On Nov 28, 2004, at 10:08 PM, Hilmar Lapp wrote:
> > I'm not saying this change of direction may be a show-stopper for any 
> > dependent package like bioperl-db. All I'm suggesting is let's be 
> > clear that this *is* a change of direction for a core interface, and 
> > let's give it some time to phase it in and to iron out wrinkles, both 
> > on the end of bioperl itself as well as the end of people who write 
> > software against bioperl. Let's give it some time to see how it works, 
> > and how it works under stress, before letting it lose on the general 
> > public who just wanted to get some bugfixes on the 1.4.0 release or 
> > some additional parsers.
> --
> Aaron J. Mackey, Ph.D.
> Dept. of Biology, Goddard 212
> University of Pennsylvania       email:  amackey at pcbi.upenn.edu
> 415 S. University Avenue         office: 215-898-1205
> Philadelphia, PA  19104-6017     fax:    215-746-6697

More information about the Bioperl-l mailing list