On Fri, Mar 01, 2002 at 08:07:56PM -0800, David Waring wrote:
> I am creating a new class: RevCompSequence to allow reverse complementing of
> Sequence with all of its Features. It uses a ProjectedFeatureHolder to
> project the features. I have included a createFeature(Feature.Template)
> method which gets the projected location and projected strand of a
> Feature.Template and then creates a new feature on the original Sequence.
> Anyone see any problem with that? Should I make it optional to reflect it
> back onto the original? My choice is no but I am open to suggestions.
No, reflection back is a perfectly reasonable thing to do.
If someone is using a Sequence and can't cope with new features
being created by another piece of code, they should have
a suitable ChangeListener installed, vetoing feature changes.
I wouldn't bother with making the writeback optional, either.
If someone wants to add features without writeback, they always
have the option of constructing a ViewSequence. You could
always mention this possibility in the javadoc for your class.
> Another question. How should a reverse complement of a NON-stranded feature
> behave? Specifically should getSymbols() return the same SymbolList as it
> would on the original Sequence? For StrandedFeatures it is obvious, of
> course it should. But I kind of feel that a NON-stranded feature should
> return the rc view. Think about looking a Sequence, rc'ing it and selecting
> a region for some non stranded feature. I think getSymbols() should show the
> same sequence that you selected. Any opinions?
My vote would be that any Feature on a reverse-complement
view should behave in exactly the same way as that Feature
would if the sequence it was attached to was a `normal'
sequence implementation, rather than a view. So yes, I'd
agree that you should be returning a portion of the RC view
in this case. To me, at least, that seems to be following
the principle of least surprise.
Anybody else have views on this?
Thomas.
_______________________________________________
Biojava-l mailing list - [EMAIL PROTECTED]
http://biojava.org/mailman/listinfo/biojava-l
