[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
it.
> 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....
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
iRNAi, do you?
http://www.mekentosj.com/irnai
*********************************************************
More information about the Biococoa-dev
mailing list