[Biojava-l] Alignments

[Matthew Pocock]

Hi David,

David Waring wrote:
> I will soon be adding a bunch of classes related to Alignments. I should
> have these ready today or tomorrow. I hate naming things so if anyone can
> come up with better names especially for ARAlignment I am open to
> suggestions.
> 
> Interface UnequalLengthAlignment (allows having sequences of different
> lengths)

I presume that this is api-short-hand for inserting gaps before or after 
a particular sequence in the alignment? This would be functionally 
equivalent to using a gapped sequence to view the alignment component 
and adding gaps at 0 or at length.

> Interface ARAlignment (allows adding and removing sequences)

Usefull functionality

> Interface EditableAlignment (allows editing, and shifting bases)

Again, usefull to have.

> Class FlexibleAlignment (implements all 3 of the above)
> Interface AlignedElement (holds label, SymbolList, location)
> Class SimpleAlignedElement
> Abstract Class AbstractULAlignment
> Class IllegalAlignmentEditException
> Interface QualitativeAlignment (handles SymbolList that implement
> Qualitative)

Could you explain what Qualitative means?

> 
> May I suggest a few other things
> 
> Interface SequenceAlignment (extends Alignment)

Long overdue. Thomas, how hard would it be to knock up a 
SequenceAlignment class that was composed from an alignment and a 
feature holder?

> I think this could help in the recently discussed issues about
> SequencePanel. Anyone up for defining this one?
> 
> In addition I REALLY think that we need an interface for a GappedSymbolList.
> Since this name is already taken I guess we could call it GappedList or
> something. This way GappedPhredSequence or other classes could implement
> this interface.
> 

What methods would the gapped interface contain? I would be happy to 
make GappedSymbolList an interface and add a SimpleGappedSymbolList. 
Perhaps that would make people mad. The idea of GappedSymbolList was 
that it wrapped another symbol list, adding the ability to view it with 
gaps. GappedSequence does the same for a Sequence instance, and takes 
care of projecting features from un-gapped to gapped coordinates. Both 
classes have (or should have) methods to fetch the underlying object 
being viewed. Perhaps the need for your gapped interface goes away if we 
have a generic 'View' interface, and code would walk down the decorating 
views untill they hit one that has the funcitonality they want. Grr. 
Sometimes I don't like OOP.

How much of your new API do you think should be added to Alignment, 
rather than to derived interfaces? All the funcitonality that you have 
mentioned would seem to me to be sensible to add directly to Alignment 
(pending knowing the exact semantics of the calls you are adding).

> 
> I have some questions about how to best implement change support for
> EditableAlignment. Particularly how should changes that cascade be handled.
> Let me first define the function 'shift'. This will move bases in one
> direction or the other, filling in gaps on one side and adding gaps on the
> other. Of course shifting cannot delete bases only gaps. In the case of an
> UnequalLengthAlignment shifting bases that include the first or last base
> should not add gaps at the ends, rather it changes the location of the
> sequence withing the alignment. So there are two types of changes, adding
> removing gaps, and changing location. In addition if a sequence is shifted
> such that it extends the overall alignment, it will change the size of the
> alignment. Finally if a sequence at the begining of an alignment is sifted
> to the left, the whole alignment will shift so as to make the first base in
> the alignment = 1 again. In this cases all of the sequences in the alignment
> must be changed. The same is true if an sequence is added to the alignment
> that extends the alignment to the left.
> 
> Now how should changes be signaled to listeners. Should each change be sent
> with a FirePreChangeEvent/FirePostChangeEvent. Or should I just come up with
> a global ChangeEvent, that holds all the information? If each change, gets
> sent individually, it seems that there is a possiblity (although it should
> not happen) that a one of the events gets vetoed, and I'd have to do a
> rollback. I know this sort of things has been discussed before but I don't
> know what the conclusion is. I would like to send ChangeEvents that will let
> the listeners know what sequences have been changed, and the overall range
> of the change so that, for instance, some Rendering object would know what
> it had to redraw without having to figure it all out for itself. Any
> suggestion would be appreciated

This is where the current changeability API is a bit suckey. You can set 
it up so that the alignment listens for changes in the individual 
sequences, and forwards these (wrapping the change event as appropreate) 
to listeners on the alignment. ChangeForwarder is your friend here. So, 
when a request comes in to alter the alignment, if it will directly 
affect a property of the alignment you first fire pre-changes on the 
alignment, then call the method on the symbol lists or alignment that 
will make updates and then fire post-change. If it does not directly 
alter a property of the alignment (but may do indirectly), you call the 
appropreate method directly. When the object the alignment is composed 
from changes, it will fire pre and post change notifications, and the 
change forwarder in the alignment can pass this information on to the 
appropreate listeners.

This mess is made a bit more robust on the BRANCH_CHANGE branch as there 
are seperate interfaces for registering listeners and forwarders, but we 
are getting ahead of ourselves. Does that make things clearer? I'm most 
of the way through a rather good shiraz, so my explanation may not be 
crystal.

Matthew


> 
> David
> 
> 
> 
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
>