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