[Bioperl-l] AnnotationCollectionI and SeqFeatureI changes

Jason Stajich jason.stajich at duke.edu
Tue Nov 23 14:12:07 EST 2004


On Nov 20, 2004, at 1:39 AM, Hilmar Lapp wrote:

>
> On Friday, November 19, 2004, at 02:50  PM, Allen Day wrote:
>
>> * Bio::SeqFeatureI now ISA Bio::AnnotationCollectionI
>> * All Bio::SeqFeatureI *_tag_* methods have been moved to
>>   Bio::AnnotationCollectionI, marked as deprecated, and mapped to 
>> their
>>   analogous and mostly pre-existing Bio::AnnotationCollectionI 
>> methods.
>>
>>   Methods which were not in Bio::AnnotationCollectionI, but were i
>>   Bio::Annotation::Collection and were necessary for *_tag_* method
>>   remapping were created in Bio::AnnotationCollecitonI.
>>
>
> This is a fairly substantial if not huge change, and this is happening 
> on the main trunk.
>
> Basically, with this change the 1.5 release has moved far far away 
> from a drop-in replacement (it's not tagged yet or is it?). Bioperl-db 
> for instance is incompatible with this, and anybody using bioperl-db 
> will then need a solid 1.4 support for some time to come. It'd 
> interesting to which degree GBrowse is fine with these changes.

it has not been tagged yet.  I think Aaron is just really busy on this 
front.  But I agree all this new stuff probably should not be part of 
the 1.5 release.   I think a "grand plan" view is probably called for 
on what the architecture will be for Features.  A lot of stuff is being 
rolled out, but I am not sure many people know how this is going to 
accommodate the difficult interface between GFF3 "everything is a 
feature and identifiable" and the current bioperl "features are 
attached to sequences" model.  This is in fact something that many of 
us discussed offline and had ideas about but not sure what direction 
was really chosen.

I admit to having my head down and not paying a lot of attention, and 
am glad for you guys to be working on it, but I think if we are having 
a serious departure from the current object structure and changing 
function names with deprecation warnings, it needs to be on a different 
release version since 1.5 is really just a 1.4+ release and not a new.  
Otherwise people are not going to adopt this new release  and the baby 
(all the bugfixes that have gone in since 1.4) will get thrown out with 
the bathwater (lots of changes that some people may not want because 
they mean changing their already working code).

> I think the deprecation warnings are a really *bad* idea. The effect 
> will be that anyone who has written code against a version that is 
> older than today the screen will be cluttered over and over with 
> warnings.

>
> My suggestion is to either do this on a branch first, or if on the 
> main trunk then in a way that is completely transparent to the API 
> programmer for some time to come. You can think about cluttering 
> people's screen after 1.6.

I totally agree.

Allen, et al, not sure if you are aware, but there is also a method 
called "deprecated" which is part of Bio::Root::you should be using 
instead of 'warn' which will only warn when verbose >= 0.  It probably 
should be only printed when verbose > 0...

>
> 	-hilmar
> -- 
> -------------------------------------------------------------
> Hilmar Lapp                            email: lapp at gnf.org
> GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
> -------------------------------------------------------------
>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>
>
--
Jason Stajich
jason.stajich at duke.edu
http://www.duke.edu/~jes12/



More information about the Bioperl-l mailing list