[Biococoa-dev] More on BCSymbolSets

[Charles PARNOT]

At 9:16 AM -0500 3/6/05, John Timmer wrote:
> >
>> On Mar 6, 2005, at 1:27 AM, Charles PARNOT wrote:
>>
>>> OK, that works well for BCSequence, but how about that code:
>>>
>>> BCSequenceDNA *dna=[BCSequenceDNA initWithString:@"ATGTTTGAT"
>>> symbolSet:proteinSymbolSet];
>>
>> My understanding of the whole new BCSequence construction, is that the
>> user only needs to use BCSequence. The framework will deal with its
>> subclasses if needed. So in that case, the above would change to:
>>
>> BCSequence *dna=[BCSequence initWithString:@"ATGTTTGAT"
>> symbolSet:proteinSymbolSet];
>>
>> which returns a protein object, named 'dna'.
>>
>>
>> Can we prevent the user making such ambiguous situations, maybe by
>> making the BCSequence subclasses private? Or will that break things?
>
>Don't know if it would break things, but Alex and I would be disappointed if
>they got made private, and I find it hard to believe that we'd be the only
>ones who want to work that way.  Anyway, the point that Charles is trying to
>make (I think) is that symbol sets open up a new set of options for having
>things winding up internally inconsistent, and we need to police that.  In
>this case, specifically, we need the init method of subclasses to ensure
>that the symbol set they've been handed is of the appropriate type - very
>simple, a line of code.

Exactly my point. Koen, remember we need to give access to both a generic class (BCSequence) and typed sequence classes (for John and Alex... well, and potentially other users too!).


>The more significant question is what should be returned.  Nil?  an error?
>Use the default symbol set for that sequence type instead? Go 10.3 only and
>throw an exception?
>
>My vote would be to fall back to the default if we get anything non-sensical
>handed to us.

I thought that too (see my code) but maybe another option is to use an empty set, which means you get empty sequences no matter what you do. The reason is you want something not ugly enough to generate runtime errors (no nil, no exception), but still strong enough that the error can not be missed (be it the user of the framework, or the user of the BioCocoa-based app, doing something silly).

charles

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