[Biococoa-dev] BCSequenceRecord

[Alexander Griekspoor]

You think?! Just kidding ;-)

About the implementation, even if we use single byte const chars, I  
still like the idea a lot of Charles to use NSMutableData as the  
internal datastore and provide an accessor to it. The NSData -bytes  
method casted to const char will give you direct access to the c  
array. Indeed the ivars can best be held read only as all editing  
should occur through class methods that also do the syncing of  
features/annotations. I would have absolutely no problem (certainly  
for performance reasons) to just have the accessor be - (NSData *) 
sequenceData; while internally it really is an NSMutableData. John  
uses to be very picky about this one, but it is fair I think that the  
user should respect that things only work for what we tell that we  
hand him, not what he really gets. I know that also Apple does this,  
their methods sometimes tell you you will get an NSArray, while in  
fact it is a NSMutableArray. But don't blame them if you start  
editing the array and things behave weird.

Again the main reason for going for NSMutableData instead of directly  
using a char array is that we don't have to do the memory allocation/ 
management. For instance from the NSMutableData  documents:

- (void)replaceBytesInRange:(NSRange)range withBytes:(const void *) 
replacementBytes length:(unsigned)replacementLength

Replaces the range within the contents of the receiver with  
replacementBytes. If the length of range is not equal to  
replacementLength, the receiver is resized to accommodate the new  
bytes. Any bytes past range in the receiver are shifted to  
accommodate the new bytes.

This is just fantastic instead of having to do all malloc and pointer  
shifting etc ourselves!
Cheers,
Alex

Ps. Any clues on the spam stuff, I think none of my 5 messages have  
yet been posted to the list while you Koen for instance got the  
direct one immediately so it seems.


On 9-jul-2005, at 21:16, Koen van der Drift wrote:

> On Jul 9, 2005, at 2:36 PM, Alexander Griekspoor wrote:
>
>
>> I'm not sure, the question is how heavy the annotations will be, I  
>> think not too much. The question why I'm kind of reluctant is the  
>> idea for instance that NSAttributedString would be separated into  
>> an NSString and an NSStringAttributes object, somehow this doesn't  
>> make sense to make. It will also be more problematic to keep  
>> things in sync after editing, and would certainly require all  
>> kinds of notification and delegates "hacks" to make it work. In  
>> the end I don't think we even need light weight sequences so much.  
>> After all, we're passing around pointers to objects, so imagine a  
>> bcalignment, it will get the pointers to the sequences, it will  
>> use the ivar to the raw data to get access to the char arrays, and  
>> do it stuff. Whether or not the bcsequence object contains the  
>> annotations or not doesn't make a millisecond or kb or ram  
>> difference!! This is one of the nicest things of the char array  
>> setup in fact. I don't like the idea of a separate record for the  
>> annotations too much. The question in the end comes to whether we  
>> see the sequence as the center of our universe, also containing  
>> annotations, or whether we see the metadata as the most important  
>> part, with one of its attributes being the sequence data in the  
>> form of a bcsequence object. I don't get the overall picture. If  
>> you really want to do the separation, it would make even more  
>> sense to me to make BCSequence the metadata/annotations object and  
>> have a separate BCSequenceData object...
>> Alex
>>
>
> Hi Alex,
>
> I think you convinced me :)
>
> Let's start implementing the char array and BCSequence structure  
> first.  Are we merging BCSeqeunce and BCAbstractSequence so that we  
> just will have a regular subclass - superclass structure?  For the  
> ivars I suggest to make them immutable:
>
> const char *sequence
> NSArray *symbolArray
>
>
> And what will be the role of the BCParser class? It's still not  
> very clear to me how this will fit into the BCFOundation picture.
>
> cheers,
>
> - Koen.
>
>
>

*********************************************************
                     ** 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
                   E-mail: a.griekspoor at nki.nl
             AIM: mekentosj at mac.com
               Web: http://www.mekentosj.com

                  EnzymeX - To cut or not to cut
              http://www.mekentosj.com/enzymex

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20050710/a606cfe5/attachment.html>