[Biojava-l] Immutable Features

[Thomas Down]

On Wed, Dec 12, 2001 at 02:17:31PM -0500, Michael Jones wrote:
> Just out of curiosity what was the design decision that led to 
> Features not being Immutable and only allowing modification of 
> Feature.Templates? 


Hmmm, I take it you mean `not mutable'?

Well...  the Feature interface hasn't changed for a long time
now (well before the release of BioJava 1.0...).  At that time,
we were very cautious about any form of mutability in BioJava
objects.  In addition, there was the feeling that it should be
up to a given Sequence object as to which kind of Features it
wants to support.  With ChangeEvents in place, mutable features
make a lot more sense -- and Sequences have a chance to veto
any changes which they don't like.  Similaryly, if I take
an `exon' feature which is a child of a `gene', then try to
change it's type to `blurdybloop', that's potentially another
ChangeVetoException.

There are still a few places where things get ambiguous.  One
that comes to mind is replacing the location of a child feature
with a new location which extends outside that of the parent.
Is this a ChangeVetoException, or does the parent's Location
dynamically get recalculated.  I guess the correct behaviour
depends on circumstances, so we maybe shouldn't get too stressed
about this.

Anyway, I'd be interested to hear what the level of demand for
this is.  I'd certainly be happy to help out on the implementation
front if there is consensus on how it should all work out.  Although
I'd like to see the long-awaited 1.2 release branched first.

If we do go down this route, there's another debate which I'd
like to see happen in parallel.  A few people have asked recently
about features implementing multiple Feature interfaces.  In
principle there's no reason not to (especially if we use code
similar to the current ProjectionEngine system to dynamically
generate the actual objects :-), but the current Feature.Template
system breaks, because you can't multiple-inherit the classes.
My suggestion is that we should consider phasing out the
Feature.Template system (this can be done quite gradually), and
replace it with a system where the template is just stored as
a Map or Annotation or something.  Is the demand for multiple
feature inheritance still there?  If so, does this strategy sound
sensible?

   Thomas.