[Biococoa-dev] more ramblings

[Koen van der Drift]

On Dec 2, 2004, at 2:21 AM, Alexander Griekspoor wrote:

> Very nice summary John, this indeed the state of the union ;-)
>
>> Koen, who doesn't like the idea of sequence subclasses, wants to make 
>> all
>> methods accept all sequences, even if they can't make any sense out 
>> of it -
>> for example, a nucleotide sequence being sent to a hydrophobicity
>> calculator.  Nonsense like this could be handled by throwing an 
>> exception or
>> something similar.
>
> Again, this is the number one reason why I 'till now chose for typed 
> subclasses, and still thinks it's a better option.
>>
>> Alex and I feel that it's better to help the developer recognize 
>> potential
>> errors by having type requirements for these methods, where possible. 
>>  The
>> converse is that I can't see any possible benefit of allowing a 
>> situation
>> that can throw an exception when it can be prevented easily.  Koen 
>> may be
>> able to explain benefits I can't see, since he is advocating this.
>
> He mentioned one, but it doesn't do it for me yet.
>>
>> One compromise would be to have the actual method implementation 
>> (which is
>> in a non-sequence class) accept any type of sequence, but place the
>> convenience method that calls it in the specific sequence class(es) 
>> that
>> should be used with the method.  Again, I'd prefer otherwise, but if 
>> I get
>> outvoted on that, please allow me this concession.
>
> It's better to choose, if we go for subclasses there's no advantage to 
> do this, it even removes one as it lifts the type requirements!
>


Well let me add some points here. Although I never liked the idea of 
subclassing BCSequence, I think you guys are right that if we use 
one-liners it is better to call them from the appropriate subclass. But 
I still like the idea of have the wrapper test the sequence type first 
before continuing. It might be nonsense to do that, but the result 
won't be - because there are no results.  Just returning nil will be 
sufficient, no need to start throwing exceptions around ;)

My main reason for being against the subclassing was because at the 
time that I brought it up there was so much code-duplication, that I 
was wondering if there was a way to make it easier to maintain and 
understand. We didn't talk much about one-liners and convenience 
methods then, which is indeed a reasonable argument pro subclassing,   
However, I don't like the idea that was suggested in another recent 
mail, to also make subclasses for DNAStrict, proteinstrict, etc. These 
are only variations on the existing three subclasses, and should be 
differentiated from each other by their symbolset and/or sequencetype.


cheers,

- Koen.