[Biococoa-dev] more ramblings

[John Timmer]

>>> 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.
>> 
>> Anyway, personally, I feel that throwing errors at compile time rather
>> than
>> while a program is running is the better option
> My point exactly! Tell the developer he does a stupid thing (or help
> him to prevent his users do stupid things).

Okay, since Alex seems to agree to some extent, let me just clarify what I
think is the issue:

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.

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.

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.

I hope that's a cogent explanation of things.

JT
_______________________________________________
This mind intentionally left blank