[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