Just to clarify one thing regarding the section below. I wasn't suggesting
our methods themselves were going to crash the app, but rather they make the
following situation more likely:
bob = [genericSequence complement];
bobArray = [bob sequenceArray];
id aSymbol = [bobArray objectAtIndex: 5]; <- app crashes here
Part of it may be just how I do things: when designing my own objects, I
put a lot of error checking in to the initialization and transformation
routines, and then assume for all other purposes that I have an object with
valid internals. Faced with using a generic sequence, I wouldn't be able to
do that, and I'd be checking its length all the time to make sure it's
valid.
Anyway, I do agree that your plan for moving forward's a good one, and sorry
you've picked up a cold as well.
Cheers, JT
>>> Uncertain return values mean that careful developers will have to surround
>> every method call with tests (did it return nil? Was the returned sequence
>> length 0?) that slow the code down and are very tedious to constantly
>> implement.
>>>> How are we going to define a sensible return value for a method call that
>> makes no sense in the first place? Is nil appropriate? Throwing an
>> exception?
>> If a header says a method is handled, it should not crash the app. So, at
> least, I don't think throwing an exception is appropriate in the case of a
> generic sequence. I would also ban nil as much as possible.
>> Here are examples of possible behaviors:
> * complement of a protein --> self or empty sequence
> * cutting a prot with enzyme --> return empty arrry or array with just the
> prot
> * hydrophobicity of DNA --> return 0
> * align a DNA and prot --> align next to each other
>> I don't think it will crash the app as long as you get objects of the expected
> types. It may result in weird behavior on the final app, but only in cases
> where the final user does equally weird things.
_______________________________________________
This mind intentionally left blank