[Biococoa-dev] Sequence factory

[Alexander Griekspoor]

Hi Charles,

To begin with the last part:

> I can elaborate more and give a possible implementation (which would 
> mostly be some copy and paste), if  you don't already all hate me!
Absolutely not, I think we all agree that the more people share their 
opinion the better BioCocoa will be in the end. It's actually very nice 
to have someone come in with the "User" perspective at this stage, 
especially now we're having a bit of trouble deciding the best strategy 
to go for sequence handling.

> In fact, some of your factory methods are inside the subclasses and 
> could be all put in the proposed superclass category, like 
> 'dnaSequenceWithString:', etc... In a way, the factory code is thus 
> already quite spread out (this would have to be in the TODO list 
> anyway and could anyway be taken care of with the current design).
You're right, and yes go ahead, all ideas are welcome!
>
About the following:
>  In my short life as a programmer, I have mostly used Cocoa, and I am 
> very used to the design patterns of the Apple's framework and of 
> course, love them. If I was ever to develop an application based on 
> BioCocoa, I would want to be able to type (or the same with 
> BCSymbolList):
> 	mySeq=[BCSequence sequenceWithString:@"AGTAGATTTGAGGT"];
>
> but I would hate to have to go through the doc and find out I have to 
> do instead:
> 	factory=[BCSequenceFactory sharedSequenceFactory];
> 	mySeq=[factory sequenceWithString:@"AGTAGATTTGAGGT"];
>
> Why do I need 2 classes? And I have to do this every time I use a 
> sequence, which is going to happen very often? Why could not it work 
> like NSString, NSNumber, or any other class, and have factory methods 
> built into the class itself??

That was exactly my problem with this approach as well. Yet, it has 
some clear advantages, code centralization being the most important, 
but also think about caching (my favorite one is restriction enzyme 
analysis, a (shared/factory) object could initialize 600 enzymes, which 
can simply be kept around as long as you need. In contrast bringing 
this into a sequence object for instance would mean that you have to 
reinitialize the enzyme plist again and again.
Now, coming back to your remark about the code. My proposal was (and 
still is) to add these kind of (standard apple-like) methods to the 
BCSequence class as convenience methods. You would simply call:
	mySeq=[BCSequence sequenceWithString:@"AGTAGATTTGAGGT"];
and behind the scene this (in this case class) method would invoke:
	factory=[BCSequenceFactory sharedSequenceFactory];
	mySeq=[factory sequenceWithString:@"AGTAGATTTGAGGT"];
The best of both worlds. The User won't notice the difference, except 
that he now has the option to choose for simplicity or to optimize 
things if needed (for instance retaining the tool object).

> In a way, BCSymbolList would look a little bit like a class cluster, 
> except there is no need for a placeholder class (actually, this could 
> also be implemented to automagically take care of -(id)initWithString 
> when called on the superclass), and except some of the subclasses 
> would be public (if somebody using BioCocoa wants to use more static 
> typing and catch more problems at compile time).

Could you comment a bit more on this Charles? It's not entirely clear 
to me what you mean.

> Remember this is just a comment of a BioCocoa newbie that may miss 
> some of the subtleties... and well, I could still live with the 
> current design!

We didn't start so long ago either ;-)

And now that I'm at it anyway, have a great Christmas holiday everyone!
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

                             iRNAi, do you?
              http://www.mekentosj.com/irnai

*********************************************************