[Biojava-dev] Re: [Biojava-l] Mutable Features - strand?

[Matthew Pocock]

Hi Thomas,

What if ProjectionContext itself retained the non-property methods it 
has (create/removeFeature, add/removeChangeListener, getShema, 
project*), and then we have a design-pattern as follows for all of the rest:

In a given impl of ProjectionContext, we supply projecters and 
unprjectors for properties e.g. projLocation, srcLocation or some other 
sane prefixes. Then, the proxy code generator introspects the 
ProjectionContext, and wherever it finds a proj or src method matching a 
feature property, it delegates to that, and wherever it doesn't it 
forwards the call on directly to the underlying feature.

One other issue is that most (all?) of the current projection impls are 
creating new feature instances for the same underlying features each 
time you view them. This makes some things hard. We could put some 
standard feature caching (read weak references) into 
ProjectedFeatureHolder to solve this. It's particularly anoying in the 
GUI code.

Please holler if you think this way leads to madness, or if you like it. 
I'm starting to code bits of this up but won't commit anything to CVS 
untill there's been some discussion.

Matthew

Thomas Down wrote:
> Hmmm, if we want mutability of projections (something that
> doesn't convince me 100%, but I suppose it has its uses),
> how about adding methods to ProjectionContext of the form:
> 
>     public void setStrand(StrandedFeature f, Strand s)
>         throws ChangeVetoException;
> 
> That still keeps the projection system nicely flexible,
> and the individual projection objects very simple (just
> makes calls into ProjectionContext).
> 
> I guess the alternative is to gut ProjectionContext and rewrite
> it with pairs of methods like:
> 
>     public Strand projectStrand(Strand s);
>     public Strand reverseProjectStrand(Strand s);
> 
> This moves a bit more code into the projection objects, and
> maybe simplifies writing ProjectionContexts a little bit.
> 
> If I was writing the whole thing from scratch today, I might
> consider the second option.  But I think the first option,
> which doesn't require any significant changes to existing
> code, is probably a better bet for BJ1.4.
> 
>     Thomas.
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at biojava.org
> http://biojava.org/mailman/listinfo/biojava-dev
> 


-- 
BioJava Consulting LTD - Support and training for BioJava
http://www.biojava.co.uk