Subject: [Biococoa-dev] New Structure for BioCocoa part II
Alexander Griekspoor
mek at mekentosj.com
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!
Cheers,
Alex
*********************************************************
** 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
4Peaks - For Peaks, Four Peaks.
2004 Winner of the Apple Design Awards
Best Mac OS X Student Product
http://www.mekentosj.com/4peaks
*********************************************************
More information about the Biococoa-dev
mailing list