[Biococoa-dev] BCSequence implementation

[Philipp Seibel]

Ok i see ...
I'm a newbee and i don't know everything jet ..... ;-)
Let me try to make another suggestion ..... ok ok possibly it was also 
there before ... but it's worth to risk i think ;-)

What about to make several Frameworks from the beginnig like it's 
organized in the Cocoa Framework.

There is the plan for a BCFoundation / BCAppKit framework i noticed.

For my HMM plans i think a BCHMM.framework would be nice ....
Only because there are so many elementary classes for HMMs, it will be 
confusing putting them all in the BCFoundation framework

what do you think ?

Phil

Am 23.02.2005 um 14:39 schrieb Alexander Griekspoor:

>> you are completely right. It was my fault. I think its nice to have 
>> some categories in one header file, but not due to performance 
>> issues.. (you are right).
> No problem, indeed it's a good idea to organize the code in categories 
> inside a single header file, it nicely groups all the related code.
>
>> I took a look into the BCAbstract Sequence and recognized that the 
>> Object stores the Sequence in a NSArray of BCSymbols. Thats not 
>> really good i think. Imagine handling complete genome sequences or 
>> other stuff. I think we need to store it in a NSString or even simmpe 
>> char array. There could be of course accessor methods for BCSymbols 
>> .... but we really need to care about memory and performance issues. 
>> Especially in the Foundation framework.
> Again this discussion also predates your arrival at the framework, 
> perhaps you can take a look in the archives...
> The basic thought here is that we have made the decision very 
> carefully to go for our own BCSequence and BCSymbol class (although 
> the design has recently changed quite dramatically with the arrival of 
> Charles ;-). The reason is pretty simple, although many similarities 
> an NSString is not the same as a sequence. The characters are 
> different, many features are different.
> Of course we could go for char arrays but that will basically get rid 
> of all the benefits Cocoa (and object oriented design) has to offer us 
> from the start (and thus basically kill the reason to build the 
> framework in the first place).
>
> By having our own BCSymbol and BCSequence we think we have an oriented 
> design mimicking NSString (but better) which is way more powerful than 
> basic c arrays can ever be. Well, I hear you think, "that's nice, but 
> my computer will never work with a genome of objects (memory and 
> speedwise)!" That correct, but therefore we are using a simple trick. 
> All symbols are so-called shared instances, meaning that only a single 
> instance is allocated and in memory, and all a sequence array consists 
> of are pointers to this one instance. Yes, this will take up more 
> memory than a char (around 4 times?) but that's more than worth the 
> benefits Cocoa will give us. And to relieve you further, yes there are 
> char and NSString accessors that will give you the desired variable if 
> you need them. But just to make sure, it's a deliberate choice that 
> ALL internal representations of sequences should be in the form of our 
> own BCSequence objects wherever possible. Ideally this includes 
> alignments. I don't think it's a good thing if a method would consist 
> of converting a BCSequence to a string, do the manipulation, and 
> reconvert the string to a BCSequence. All this should be done natively 
> in the BCSequence format, and if that gives one trouble, we should 
> rethink/extend the BCSequence class.
>
> Now, I do realize that with the arrival of more people, it's obvious 
> that they are gonna ask themselves and the list (no offense, please 
> do!) the questions that we asked ourselves as well during the initial 
> design of the setup we now implement. Therefore, I think that once the 
> basic BCSequence system is up and running (BCSequence et al, 
> annotations & features, and SeqIO) documentation will become the 
> number one priority. As I want to do spend a bit more (PR)  words on 
> BioCocoa on our website anyway, to generate more knowledge and 
> traffic. I'll see if I can combine that with some more explanation of 
> the basic architecture of the BCSequence setup. Until the 1.0 release 
> of BioCocoa and if anyone agrees with the idea, it can become the 
> temporarily (developer) homepage of the new BioCocoa framework, 
> leaving the current one intact as long as we're still in beta (or 
> alpha ;-) phase. Peter, any thoughts on this one?
>
>> Another Question:
>>
>> What about a BCMutableSequence ... id like to implement one for the 
>> Alignment classes
> At the moment we've decided to go for a class that's mutable from the 
> beginning, mainly for both performance and technical reasons. Perhaps 
> Charles and John can talk a bit more about this, and I remember a 
> discussion about this issue, so there must be a thread in the 
> archives... It would be nice to have an optimized immutable version in 
> the future, but again Charles might explain you better why that's not 
> so easy with the current implementation, he designed the class cluster 
> approach.
>
> So all in all, please don't feel offended by the answers, all your 
> comments are more than welcome and the lack of documentation doesn't 
> really help starters. Feel free to ask us to explain the rational 
> behind different design choices, it will help writing the 
> documentation and FAQs for one!
> Cheers,
> Alex
>
> Ps. finally I don't want to sound too motherly but as a general "rule" 
> please first let the list know the plans we all have on what we will 
> do before submitting anything in the CVS (for instance the 
> BCAnnotableSequence.h/m files I noticed). This especially when you 
> would like to see folders added and/or files (simply outline your 
> proposed work in a post), then at least we know not to remove them ;-) 
> Right now my current focus is the BCAnnotation/Feature part, the 
> implementation of them in BCSequence and BCSequenceReader/Writer.
>
> *********************************************************
>                       ** 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
>
>           LabAssistant - Get your life organized!
>           http://www.mekentosj.com/labassistant
>
> *********************************************************
>
>