[Biococoa-dev] more ramblings

[John Timmer]

>> The question then becomes how to determine which type of sequence to
>> return.
>> The way I would imagine is to have a flag to determine whether to ask
>> for
>> user input - this could put up a standard dialog box.  If the flag is
>> false,
>> the factory method could create each type of possible sequence, then
>> use the
>> sequence counted set to look for undefined symbols.  Compare the
>> results,
>> and take the one with the fewest undefined symbols.  In case of a tie,
>> default to DNA>RNA>protein.
> 
> Sounds good, this code can also go in the factory class. However, I
> don't think we should use a dialog box for the framework. This is the
> sole responsibility of the developer who uses BioCocoa.

Okay, skip the dialog.  I'll try to spare some time this evening to
implement this, since it's my idea and seems on the surface to be fairly
simple (I'm sure that will be wrong).  I guess it would go in the case
BCSequence untyped section of the code you showed.

 
> 
> Could you show a more concrete interface? It's still kinda vague to me
> :(

Okay, I'll try to throw something together this weekend.  Actually
implementing this is going to be problematic, since a lot of the internals
are going to depend on other parts of the code being implemented.  We're
going to have to nearly complete the implementation before it actually can
be tested.


 
>> The last issue seems to be around the quote from Koen:
>>> I agree, but let's then focus on having these one-liners in BCSequence
>>> only, not in the subclasses.
>> I remember this quote as bothering me when I first read it, because
>> there
>> are some one liners that clearly belong in a specific sequence
>> subclass (ie
>> - finding the longest open reading frame should not be available to a
>> protein sequence, and finding the hydrophobicity should not be
>> available to
>> nucleotides or codons).  I seem to remember that reading further
>> alleviated
>> my concerns on this, but I can't remember how.  Since Alex and I share
>> this
>> concern, could you clarify what you meant here, Koen?
> 
> 
> If we add code to a wrapper that checks if the type of sequence then I
> don't see any problem. If the sequence type by accident is the wrong
> one (which I really don't think is going to happen), the wrapper should
> return nil, or an error, or an NSNotification. Hope that's more clear.

You haven't coded for actual users much have you?  ;).  You'd be amazed at
the seemingly impossible situations they generate on a regular basis -
anything can and will happen.

Anyway, personally, I feel that throwing errors at compile time rather than
while a program is running is the better option, but I have no problem being
outvoted on this.  A compromise would be to have the wrapper accept any
sequence, but only add the one liner to the specific sequence class that
should call that method.
 

Cheers,

JT

_______________________________________________
This mind intentionally left blank