Subject: [Biococoa-dev] New Structure for BioCocoa part II

[John Timmer]

> but if it is 
> even confusing or unclear for the BioCocoa developers, I can imagine
> how confusing it could be for users of the framework!
I wasn't saying that I was confused, just that (for the reasons my post
detailed), I was going to use the subclasses directly no matter what, so I
didn't pay careful attention.  Of course, if I had paid attention, perhaps I
would have been confused....

 
> For the record, I didn't initiate the current discussion about the
> design of the BCSequence classes. I think it was a conspiracy from the
> guys who went to wwdc :)
I wasn't accusing!  I just know that you seem to have felt the strongest
about this, so I asked for your opinion specifically.

> Anyway, my main gripe with the subclasses was that when we first
> started implementing the code, we were duplicating a lot of code over
> all subclasses. 
Yes, that situation was my fault - it took me forever to go back and clean
up the nucleotide subclasses.  I'd get so much more done in BioCocoa if I
didn't have to keep doing research!  Anyway, it's fixed now, so I hope you
gripe less.


> IsoelectricPointCalc ic = new IsoelectricPointCalc();
> pI = ic.getPI(protein, true, true);
> 
> The code throws a exception when the wrong type of sequence is used.
> Indeed not an ideal situation, since as you stated correctly, it might
> crash the program. And to be honest, I have currently no solution to
> prevent that.

There's two other problems with that approach - one is that ObjC has two
different types of exception mechanisms, and the better of them isn't
available on 10.2, which is what we're targeting right now.  The other is a
general philosophical one:  some people feel strongly that you should never
code planning to throw an exception - they should be reserved for bad
situations that are beyond your control (damaged bundle, network failure,
etc.).  We may, already or at some point in the future, wind up with one of
those people developing with us, which would mean they object to that sort
of method on principle.  Which means more arguments.

Anyway, does anyone know why the BioOther groups chose a single class for
sequences?  And how does that affect what functions are performed by
sequences themselves?  I'm just wondering if there was an actual discussion
of design options along the lines of what we're having when those were set
up.

JT