[Biococoa-dev] Comments on BCAnnotation

[Philipp Seibel]

Hi,

Am 24.02.2005 um 07:17 schrieb Charles PARNOT:

> After going through your code, Alex, here are my comments:
>
> * we should make BCAnnotation and BCFeature immutable and thus not 
> have any setter; for instance, the annotations would otherwise have to 
> be physically copied every time a piece of sequence is copied and 
> pasted or used for alignement, etc...
you are definitly right. There is perhaps one problem, but perhaps it 
isn't a real problem ;-)... what happens with the BCFeature positions 
if i insert gaps into the sequence. If the positions have no set method 
everybody has to know that this positions are the ones without gaps.
I'm also not sure wether we need a special BCSequence class for 
alignment or not. Perhaps we need only a BCMutableSequence with the 
corresponding BCSymbolSet including a gap-symbol. This is open for 
discussion ....


> * I don't like the comparison methods names; why not stick to the 
> Cocoa way, which is simply 'compare:' using 'compareName:' and 
> 'compareContents:'. And I am not sure why you would need a ascending 
> and descending method when one can use reverseEnumerator?
This is what i think, too.

> * In the comparison: more generally, if the Contents are of the same 
> class and both respond to 'compare:', then this is what is used
>
> * the data type should be an ivar, if you want to preserve annotations 
> coming from another app; in which case the contents is NSData; more 
> precisely, when unarchiving, if the class is known, the contents is 
> unarchived; otherwise, the ivar 'contentsClass' stores the class name 
> and the ivar 'contents' stores the unarchived data;
>

I committed a very very simple start for the BCAlignment class, please 
take a look and tell me what you think we need.
Next point are scoring matrices. I would suggest a handling similar to 
your handling with the genetic code stuff. We store the PAM etc in 
plists, but i think we need to be carfeul with storing the matrix in 
the object. perhaps a int** is the best. Anyone a good idea ?

ok thats for now

Phil