Subject: [Biococoa-dev] New Structure for BioCocoa part II

Alexander Griekspoor mek at
Sun Jul 3 07:46:38 EDT 2005

I hope you are still hanging in there. Now, how do we implement our  
"char array containing sequence objects"?

There are a number of things that pop up in my mind, which I haven't  
really thought about much or have a solution for. But I just bring  
them up. I suggest everyone to do the same so when get an idea where  
the problems are, and what we have to think about.

- The singleton system remains almost unaltered, I think it works  
really nice and has the properties that we want to present to the  
outside world right?

- What about symbolsets and the creation of new sequences?

- The class cluster design of sequence objects. Is it still  
necessary, is it correct, flexible? As said, phil and I had problems  
with it, and phil was not sure if it was implemented fully correct,  
but he'll chime in I guess. Purely from complexity towards novel  
users (and people like me who had to get back in again ;-), I would  
like to see it disappear if possible.

     - Do we need subclasses for certain sequence types like  
proteins, dna, rna? I guess yes. Do we need a class cluster for this  
or does simple subclassing do?

- How to handle the main char array? An NSData object like charles  
suggested, or do-it-your-self management?

- How accessible is the c-array from the outside? Read only? It must  
be readable at least so for instance an alignment object can use the  
string for its work (à la nsstring's getCString method). I would not  
encourage direct changing of the char array from within another  
object, for instance to prevent out-of-sync problems with annotation  
positions. For that we have things like -insertSequence:atPosition: etc

- Is this the time to also have a mutable and immutable version?  
Charles will say yes I guess ;-) All editing methods on the array  
could be added only to the mutable form. Editing in general is  
something we need more c experts for, how to insert symbols for  
instance and handle it memory-wise?

- What about sequence sets, already brought up for alignments:  
wrapper objects around multiple objects, containing metadata  
(annotations and friends) for the group. Even more powerful would be  
column editing (editing all sequences at once, coordinated by this  
object) and position specific (column specific) annotations. Another  
thing would be file export, turn for instance a sequence set into one  
fasta file.

- Speaking of FileIO, I guess that has to be implemented anyway, and  
depends on how we do the initialization of our bcsequence objects.  
The interface to BCSequence should not necessarily be very different  
than it is now. Only internally things are organized differently.

Finally the topic of recent days:

- Phil's diagram. Yes, great structure! One of the other decisions  
discussed was indeed to have a modular structure, with a simple core  
(centered around BCSequence and the IO part) and all other things  
added as optional frameworks, like Phil indicated. I like the parser  
very much, but agree with Charles that we don't have to stop  
implementing things, the idea of cocoa are these blackboxes that you  
can internally change without altering the interface others see. But  
I do think we have to decide on the new BCSequence implementation  
first, as it can have really big effects (like disposing the class  
cluster potentially). Again, we don't have to throw away all things  
we did!

- BCObject vs BCStructuralObject. The latter is a nice suggestion  
Koen, BCObject indeed suggest a mother-of-all object and that it is  
not here. Another suggestion would be BCPhysicalObject (they have a  
mass, weight etc)

- Annotations. Together with the basic sequence, the file IO, this is  
the most important part of the framework. These three will make the  
new BioCocoa's core framework on which everything else will be build.  
It's indeed a difficult thing to design right, but I'm really  
enthusiastic about the discussions! Don't pay to much attention to my  
initial attempt, but it's a start.

Thanks for keeping BioCocoa going Koen, great job! Again, I'm sorry  
to not have jumped in earlier, and I hope you don't have the feeling  
to be let outside of everything, all the above is not a definitive  
thing at all. Looking forward to everyone's reaction!

                     ** 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
                  E-mail: a.griekspoor at

               4Peaks - For Peaks, Four Peaks.
        2004 Winner of the Apple Design Awards
                Best Mac OS X Student Product


More information about the Biococoa-dev mailing list