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 - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
