[Biojava-l] Feature interface changes

Matthew Pocock matthew_pocock@yahoo.co.uk
Wed, 13 Feb 2002 16:38:09 +0000


Hi all.

Since the 1.2 release is out, we can now start to think about some of 
the issues we have had with the current APIs. These changes would never 
be back-ported onto the release branch. We are commited to keeping the 
release branch APIs stable.

I think the Feature interface may be up for renewal. Here is my wish-list.

idea:
   - make the core properties of Feature and its sub-interfaces
   mutable
consequences:
   - get/set methods for things like location
   - changes must be propogated through our Feature projections
   - new code using getFoo will not be link-time compatable
   with old code
   - old code will be compatable with new API
severity:
   - i think we can live with this - we can fix the serialuid
   so that at least objects can be read/written from either
   model

idea:
   - replace the current Feture.Template instantiation system
   with an Annotation that conforms to the apropreate
   AnnotationType
consequences:
   - we could then instantiate features that inherit more than
   one feature interface e.g. Stranded & Framed
   - new code instantiating features would not be compatible
   with old code in either combination
   - possibility for much freer association of feature 'types'
   with interfaces, making ontologies of feature types more
   easily possible
severity:
   - this will break all feature instantiation code which
   will impact a reasonable number of files
   - most of the fixes can be located with search/replace

synergy:
   - the ChangeType instances that must be created for
   mutable features to be implemented can double up as
   property names in the Annotation bundles used to
   instantiate them
   - properties that can't be represented as feature
   properties due to a provider not implementing that
   interface can be stored under this key in the feature's
   annotation and this can be recognised by the annotation
   bundle's event forwarding code, providing a potentialy
   clean abstraction of the objects from their implementation.

All ideas, flames and dirty jokes greatfully recieved.

Matthew