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

[Koen van der Drift]

On Jul 3, 2005, at 7:46 AM, Alexander Griekspoor wrote:

> I hope you are still hanging in there.

Funny, I received this before part I :)

> 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?

Actually it is a combination of the singleton and flyweight patterns. 
But yes, I agree we should keep that in place.

>
> - What about symbolsets and the creation of new sequences?

Symbolsets are in my opinion very useful. Not only as an indicator of 
what type of sequence one is dealing with, but also as a datafilter.


> - 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.

Unless we hide the complete implementation, and only make BCSequence 
headers private, until now it is indeed confusing. For instance I am 
still switching between BCSequence and BCAbstrctSequence to see where a 
method can be found.

>
>     - 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?

You know my standpoint on this one :)

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

If we use NSData, than for each operation we need to get and set the 
data, so two extra steps, correct? Since we are using ObjectiveC we can 
directly use the c-string. Although that would indeed bring the 
complexity of malloc, string pointers, etc. It's good I didn't throw 
away my Simple C beginners guide book!


> - 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

Agree.

> 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!

Not left outside, but a little bit shocked, I was actually :)  But 
these new developments certainly seem to be a good step forwards. 
Hopefully this will be the final re-design!

cheers,

- Koen.

ps any chance you can post/mail the wwdc presentation?