[Biococoa-dev] BCSequence implementation

[Charles PARNOT]

Being in California, I am the last one to write and it's not fair, everybody else already said what I wanted to say!! But that's OK, the weather is good...

I still want to add my 2 cents:

* Categories: creating more categories won't reduce the 'size' of the BCSequence class at runtime, and this 'size' is not really relevant in terms of memory or performance, so I think we should not be afraid of a big big class with lots lots of methods... The analogy with NSString is perfect: does anybody complain about NSString being bloated?

* Categories files: yes there should be only one header, because potentially the user of the framework will want to import the header for the class, and it is just easier to have everything in one file then; however, having several implementation files is OK, and is even better IMO; easier to navigate

* NSArray of BCSymbols vs arrays of chars: I am on John and Alex's side; the object might be bigger, but not much much bigger; performance may be an issue at some point but it is difficult to really predict what is going to happen until you face the issue; in which case translating back and forth to a different structure might make sense if the performance is an issue  (in that I don't completely agree with Alex)

* Performance again: I don't know how many of you have used Shark, but with such a tool, we should be able to improve performance dramatically when the framework is more mature and is facing the real world; Shark is a great great application that get right to the performance bottlenecks... and they might be anywhere, and not necessarily where you would predict:
http://www.cocoadev.com/index.pl?OptimizeLater

* frameworks: it is indeed a good idea; with multiple targets, it also makes recompiling less frequent, e.g. if a file modified by somebody else is in another framework;

charles


At 10:08 AM +0100 2/23/05, Philipp Seibel wrote:
>Morning everyone,
>
>i think we should be careful by adding more and more features to the BCSequence. We have to keep in mind that for many sequence related algorithms it is better to have a sleek Object. We shouldn't design a full featured object as base class. I think categories is the best solution to add features like Annotations and Features to the Sequence object.
>
>cheers
>
>Phil

At 11:41 AM +0100 2/23/05, Alexander Griekspoor wrote:
>We previously had this discussion as well so I guess it's a relevant one. In principle I don't have a problem with categories (anymore ;-) to add these features and keep the base class lean and small. I would strongly argue to keep them in the same .h/.m file though (like apple seems to do). The real question then of course is, how do I get a slimmed down sequence objects without the added categories? Is that possible at all? And perhaps the real real question is, does that really matter? Does your code becomes slower when you add methods and arguments but don't use them? I can hardly imagine that a pointer to a dictionary (even kept nil if you don't add annotations) make a lot of difference in the end. With symbols I can imagine, but with sequences?

At 2:39 PM +0100 2/23/05, Alexander Griekspoor wrote:
>Now, I do realize that with the arrival of more people, it's obvious that they are gonna ask themselves and the list (no offense, please do!) the questions that we asked ourselves as well during the initial design of the setup we now implement. Therefore, I think that once the basic BCSequence system is up and running (BCSequence et al, annotations & features, and SeqIO) documentation will become the number one priority. As I want to do spend a bit more (PR)  words on BioCocoa on our website anyway, to generate more knowledge and traffic. I'll see if I can combine that with some more explanation of the basic architecture of the BCSequence setup. Until the 1.0 release of BioCocoa and if anyone agrees with the idea, it can become the temporarily (developer) homepage of the new BioCocoa framework, leaving the current one intact as long as we're still in beta (or alpha ;-) phase. Peter, any thoughts on this one?

-- 
Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Charles Parnot
charles.parnot at stanford.edu

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021