[Biococoa-dev] NSData

[Charles Parnot]

On Jul 19, 2005, at 3:57 PM, Koen van der Drift wrote:

> Hi,
>
> During the conversion to NSData, I ran into a couple of questions.
>
> 1. Should the symbolChar in BCSymbol also be an NSData ivar? If  
> not, I guess we need to use malloc/free etc.

The symbolChar should just be one char, not a buffer of one char.
The ivar should be:
     ...
     char symbolChar;
     ...

It seems there is some confusion when you go from NSString to string  
(buffer of chars terminated with a 0) to char. The code is not that  
different from before, and I don't think you need to change much  
stuff in BCSymbol.



> 2. Why are we using utf8 and not ascii encoding? utf8 seems to be  
> for unicode while we only need single characters.

It is basically the same thing. UTF8 can do one-byte encoding, so  
that ascii characters only use one byte. I am not sure what the rules  
are to encode other unicode characters, but the important thing is:  
if you feed an NSString with a buffer of chars, and use UTF8  
encoding, you will use the one-byte ascii characters, and when you  
convert back to chars, you will get them back.

Cocoa used to treat C string specially, but now, it is recommanded to  
treat them like other strings, with that particular encoding. It  
makes things more consistent with the rest.


> 3. I am still not sire if we should stick with the symbolString in  
> BCSymbol. Any opinions on that one?

We have it, we should keep it. It could be useful if the symbolString  
is ever different from the symbolChar. One example could be codons,  
though it is not clear how feasible it is to make codons into  
symbols. Anyway, one could decide to have symbolChar be used as an  
int (e.g. 0-63), and then have the symbolString return the actual codon.


> 4. Slightly unrelated, but I'll ask it here anyway because I notced  
> it while implementing the NSData. In the initBases method in  
> BCNucleotideDNA/RNA I see many lines such as:
>
>         [baseDefinitions removeObjectForKey: @"A"];
>
> I am not sure if I understand what the idea behind the removal of  
> the key-value pair is.

don't know... Sorry!


>
> I will probably find more issues and post them here :)

yes!


> BTW, has anyone had a chance to look at the code I posted at http:// 
> home.earthlink.net/~kvddrift/biococoa/ ?  Some feedback would be  
> nice, so I can continue making changes to my local project and then  
> commit them to cvs eventually.  Do you guys think I am on the right  
> track, let me know what you think.

I have not, but I will try to. One nice thing with CVS is you can see  
what changed, and you can always revert back to an old state. So I  
guess you should use CVS? If some source files don't compile, you can  
always temporarily uncheck the 'Target' box so they are not included  
in the build.

Thanks for doing all the hard work!

charles

--
Xgrid-at-Stanford
Help science move fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford

Charles Parnot
charles.parnot at gmail.com