[Biojava-dev] BioJava code freeze, modularization and action items for sub modules

[Richard Holland]

>
>
> What I mean is that we should try not to disrupt things as much as is
> reasonable. I am all for a pragmatic approach. While trying to be
> conservative I guess refactoring should be discussed on a case by case
> basis. To give an example: an area where I am supporting re-factoring
> is the blast parser. The package name is confusing and we probably
> need some code changes to expose more details of the parser. Are you
> thinking of any other situtations, where you think breaking backwards
> compatibility will be inevitable?

Almost all the parsers would fit this category, as would any realistic  
attempt to 'fix' the sequence model by moving bits of the APIs around  
(for instance, Sequences have Features which have Strands, but  
Locations do _not_ have Strands - which is all wrong, because Strand  
is a Location-level concept, not a Feature-level concept).

My original plan was to not even attempt to make new versions backward  
compatible, and instead to have a separate module which coerced the  
new objects into complying with the old API interface declarations (by  
using the facade model).

cheers,
Richard

> Andreas
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev

--
Richard Holland, BSc MBCS
Operations and Delivery Director, Eagle Genomics Ltd
T: +44 (0)1223 654481 ext 3 | E: holland at eaglegenomics.com
http://www.eaglegenomics.com/