[Biojava-l] Immutable Features

[Matthew Pocock]

Hi.

My oppinion, not that it realy counts now, is that we should look at 
making features mutable. The ChangeEvent system will allow us to plug in 
special-case handlers for things like "child re-located outside range of 
parent". I'd not be upset to see the feature.template stuff replaced by 
building features from an Annotation object. It was an elegant solution 
to a thorney problem, but I think we've outgrown it now. You could fill 
a slot in the Annotation for location, strand, type etc. and the feature 
realizer could find an interface or collection of interfaces that 
provides beaney accessors to as many of these as possible. All left-over 
info in the annotation bundle can then be put into the new feature's 
annotation object. As long as the interfaces are 'real' text & code in 
the CVS tree, I see no problem with auto-generating the implementations 
with bytecode.jar as and when they are needed (as long as it is clearly 
documented in the unlikely event that the core team get hit by a comet). 
We should probably write a simple (superclass, set<interface>) -> 
bytecode macro to make it all realy explicit.

Matthew

Thomas Down wrote:

> 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.
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
> .
> 
>