[Biojava-l] Should Alignment extend Sequence?
Schreiber, Mark
mark.schreiber at agresearch.co.nz
Fri Jun 6 11:07:27 EDT 2003
The only drawback with Alignment extending sequence is that it would
break all the implementations of the Alignment Interface. One
possibility would be to make a SubInterface of Alignment that extends
Alignment and Sequence and then make an implementation of that.
Your wrapper class would be one good implementation. You could also make
"factory" methods to turn a Sequence into an AlignedSequence (having
only one member) and a method to turn a normal Alignment into an
AlignedSequence with the specified name, urn, Annotation and
(optionally) FeatureResolver.
Don't worry about the wrapper pattern being hugely redundant it's a
pattern that is used a lot and works very well.
- Mark
> -----Original Message-----
> From: Bradford Powell [mailto:bcpowell at email.unc.edu]
> Sent: Friday, 6 June 2003 9:17 a.m.
> To: biojava-l at biojava.org
> Subject: [Biojava-l] Should Alignment extend Sequence?
>
>
>
> There was a good bit of discussion on this list in the middle
> of last month about making changes to the SequencePanel and
> TranslatedSequencePanel classes to allow them to be given
> SymbolLists instead of Sequences, particularly for the
> purpose of being able to display Alignments. I couldn't tell
> if this issue was resolved or not.
>
> Anyway, I spent a portion of this afternoon hacking together
> some Biojava-in-Anger-style code[1] for displaying a multiple
> sequence alignment, following using Kalle Naeslund's
> message[2] from May 8 as a guide. Rather than change
> TranslatedSequencePanel to accept SymbolLists, I decided to
> go with the second suggestion-- wrapping the Alignment in a
> Sequence. Using SimpleSequence to do this wouldn't work
> because AlignmentRenderer expects
> TranlatedSequencePanel.getSymbols to return a SymbolList that
> is specifically an Alignment.
>
> So I scavenged much code from SimpleSequence to create a
> class SimpleSequenceAlignment which implements both Sequence
> and Alignment. It is basically a SimpleSequence that
> delegates to an Alignment instead of a SymbolList. This is
> incredibly redundant.
>
> At first I wasn't happy with the thought of wrapping an Alignment in a
> Sequence-- after all, semantically an Alignment isn't really
> a Sequence, at least not in the way we usually think of
> things. Then again, the interpretation of an alignment as a
> sequence of characters in a cross-product alphabet is not
> necessarily the way one would think of an alignment initially.
>
> I looked at what extending Sequence would mean for Alignment:
> 1. Addition of Name and URN attributes
> 2. The ability to hold Features and Annotations
> I think that both of these are sensible things for an
> Alignment to do. An alignment is not just a collection of
> sequences and it would be useful for alignments to have
> identifiers of their own (particularly if one were to look at
> different alignments of the same sets of sequences). Also,
> alignments may have "features" that the individual sequences
> do not have.
>
>
> So, resulting questions are:
>
> Are there established reasons for _not_ having Alignments
> extend Sequence? (am I stepping into an old argument...?)
>
> If not, what would people think about making a change so that
> Alignments extend Sequence?
>
> If Alignments should extend that interface that is currently
> called "Sequence", should the name be changed to be
> semantically less confusing or should we just accept a
> broader interpretation of what the word "sequence" means?
>
> -- Bradford Powell
> -- bradford_powell at unc.edu
>
> [1] http://diploid.med.unc.edu/~bradford/AlignmentViewer/
> [2] http://biojava.org/pipermail/biojava-l/2003-May/003801.html
>
> _______________________________________________
> Biojava-l mailing list - Biojava-l at biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
>
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================
More information about the Biojava-l
mailing list