[Biococoa-dev] more ramblings

Alexander Griekspoor mek at mekentosj.com
Wed Dec 1 13:51:22 EST 2004

> Actually, what I suggested is to have a factory that handles the 
> creation of *every* sequence. You feed the factory with a string, 
> array, etc, and a BCSequenceType and/or BCSymbolSet, and the factory 
> returns the right BCSequence.
I think we should choose here, at the moment we did for BCSequenceType. 
Or, we adopt the whole BioJava approach with general sequences, "typed" 
bases on the used BCSymbolSet. But I don't see a real mix. In addition, 
we had many discussion about the BioJava approach and I still see no 
clear advantage, even more there are some real problems associated with 

>  If the type is not specified, then the guess code comes into action. 
> The point I am trying to make is that we should always use BCSequence 
> as a *return type* for the factory as well as within BCSequenceReader. 
> Otherwise we need a factory class for each BCSequence subclass. 
> Internally the factory creates the right subclass, and even though the 
> return type is BCSequence, the actual type will be the created 
> subclass. That's the nice thing of inheritance!
That's a goo idea.
> So maybe:
> BCSequenceFactory	*myFactory = [[BCSequenceFactory] alloc ] init];
Please make that a shared one...
> BCSequence	*newSequence = [myFactory createSequenceUsingString: 
> @"AACCTTGG" usingType: BCDNASequence];
> -(BCSequence *) createSequenceUsingString: (NSString *) string 
> usingTyp: (BCSequenceType) type
> {
> 	switch (type)
> 	{
> 		case BCDNASequence:
> 		{
> 			return [BCSequenceDNA DNASequenceWithString: string];
> 			break;
> 		}
> 		.....
> and so on.
Ok, I get it, and if you feed it [myFactory createSequenceUsingString: 
@"AACCTTGG" usingType: BCUnknownSequence];
or something alike, or nil it would call a "determine sequence" method, 
which guesses the type of sequence and then again calls the method 
above with the proper type...

> Note that in the snippet I am actually using BCSequenceDNA ;-). If you 
> guys really want it, it's fine with me if we keep those around for 
> convenience. But I still think that we should put most code in 
> BCSequence, except maybe for the init methods.
And the convenience methods not to forget!

>> Ramble #2 is about the sequence wrapper/bundle, and how to implement 
>> that to
>> handle the multiple sequences in an alignment file.  I had envisioned 
>> the
>> wrapper as holding features, and a bundle as linking related 
>> sequences.  If
>> this is the way we go, we'd have to implement both in order to handle 
>> this
>> circumstance.
>> A short summary of how I expected a bundle to work -
>> Each wrapper would have a unique bundle ID, and a reference to its 
>> bundle.
>> Features within the wrapper, features could include a bundle ID.  
>> Basically,
>> if code wanted to look at a feature, it would check to make sure that 
>> the
>> bundle reference was not nil - if it wasn't, it would take the 
>> feature's
>> bundle ID, and ask the bundle for the sequence corresponding to that 
>> ID.
>> Given that a feature should have an NSRange, this would allow the two
>> sequences to be aligned.
> Could you show a more concrete interface? It's still kinda vague to me 
> :(
Yes, I must copy that, a bundle is more a related to file structures, 
so perhaps explain it in terms of arrays and dictionaries. Or did you 
specifically address storage here? Koen referred to the BioPerl docs 
and what I saw there was something very attractive with respect to 
features and annotations....


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


More information about the Biococoa-dev mailing list