[Biococoa-dev] BCSequence

Alexander Griekspoor mek at mekentosj.com
Thu Aug 26 01:54:30 EDT 2004


>>> I think we should treat the modifications as an array of BCSymbols.
>> Hmm, yes and no. Indeed modifications are kind of symbols, thus they 
>> could have BCSymbol as their superclass. But where symbols have no 
>> clue of there location (that's determined by the array in which they 
>> are), modifications should be kept in a kind of dictionary with the 
>> location as key for instance.
>
> Yes, you are absolutely right. One issue with a dictionary is that the 
> indices change when a client requests a subsequence, how do we handle 
> that? So maybe the modifications should be a member variable of each 
> BCSymbol. The whenever inof about a BCSymbol is requested, either to 
> calculate mass, draw it, or show an inspector panel, the info about 
> the modification is available.

That won't do unfortunately I'm afraid, the BCSymbols refer to a 
singleton objects, so you can't set individual variables per symbol.
What you could do is completely mirror the symbol array with a 
modificationarray, filling up the blank spots with a empty modification 
object, that way you could just get the same position in the both 
arrays to match symbol and modification, but that's a serious hack of 
course, wastes too much memory in addition. As we have to come up with 
a solution for features/annotations as well (you can't keep a mirror 
array here as features can span multiple symbols), we have to think 
about this a bit more. As said, many bookkeeping methods for features 
and modifications can be identical in the end. While editing and using 
subranges we just have to account for keeping these objects up-to-date 
as well. It will involve a lot of range checking, but should be doable.

>> I see your point, indeed when the NCBI file lists phosphorylation it 
>> means that a particular sequence is annotated as a (potential) 
>> phosphorylation SITE and not as being actually phosphorylated. This 
>> is where I made the mistake. In that respect your right, the site is 
>> an annotation, an actual phosho-group on an amino-acid is a 
>> modification.
>
> Well, I didn't even mean it that way :) But a -Me or -PO4 group should 
> be treated as a modification, that's the general accepted term anyway 
> (post-translational modifications).  So I still  would favour to keep 
> the modifications separate from feautures/annotations.
You convinced me here.

> Also because they are probably not always requested at the same time. 
> And it's also more OOP-like to have smaller objects instead of putting 
> everything together.
Yep.

>> The only thing I doubt about is if we should implement a string 
>> version of all methods as well.
>
> Yes, you are right - I won't add those methods :)

Way to go!
Alex

*********************************************************
                     ** Alexander Griekspoor **
*********************************************************
              The Netherlands Cancer Institute
              Department of Tumorbiology (H4)
         Plesmanlaan 121, 1066 CX, Amsterdam
                    Tel:  + 31 20 - 512 2023
                    Fax:  + 31 20 - 512 2029
                   AIM: mekentosj at mac.com
                    E-mail: a.griekspoor at nki.nl
                Web: http://www.mekentosj.com

	Claiming that the Macintosh is inferior to Windows
	because most people use Windows, is like saying
	that all other restaurants serve food that is
	inferior to McDonalds

*********************************************************




More information about the Biococoa-dev mailing list