charles.parnot at gmail.com
Tue Jul 19 19:25:09 EDT 2005
On Jul 19, 2005, at 3:57 PM, Koen van der Drift wrote:
> 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:
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 :)
> 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!
Help science move fast forward:
charles.parnot at gmail.com
More information about the Biococoa-dev