[Biococoa-dev] more ramblings

[Koen van der Drift]

>> No, I meant the general wrappers that do something with a sequence 
>> (translate, pI, search, etc).
> Ok, I get it, in general you want those classes be able to handle a 
> general BCSequence object as well, and not only a specific subclass 
> per se.

No. What I proposed was that a wrapper class (eg BCTranslate) first 
checks the sequence type. If it can handle it, it will continue, if 
not, it will return nil (or an empty NSArray or whatever). Again, this 
was part of my idea not to subclass BCSequence, but to make the 
sequencetype a member of BCSequence. Which we actually already do. But 
we can also make a symbolset member for the same purpose.  If we do it 
this way, then we only have to put the convenience methods in 
BCSequence.

The alternative as proposed by John is to put convenience methods only 
in those subclasses on which the wrappers actually work. I guess that 
solution is also fine with me.

BTW, anyone oppose if I cleanup BCSequence and it's subclasses, and add 
convenience methods? This would mainly involve the rangeOfSubstring 
methods (which will be replaced my convenience methods to 
BCFindSequence), and a few other smaller parts.  Would you prefer to 
keep the rangeOfSubstring naming, or should I use the find prefix?

> Exactly, what we have to emulate is an attributed string, that handles 
> exactly the same problem(s). I think in general we don't need a 
> location object, we need a range object and I don't see why NSRange 
> wouldn't be good enough (even if our system is 1-bases).

Yes, NSRange sounds good to me. And the emulation of an attributed 
string indeed seems a way to go. I will read some of the bioperl docs 
tonight.

>>> I copy that, definitely not, but the general BCSequence class could 
>>> have a simple strict boolean that can be set.
>>
>> For what?
> For preserving the knowledge that a sequence uses  a strict symbolset

I think it's better to then extend the sequenceType enum. Otherwise we 
need to check for the sequencetype, and then for strict.

> (the other option would be to have a symbolset property inside the 
> BCSequence object.

I would really like that too. Can be helpfull in all sorts of cases.


>> BTW, what's the difference between 'strict', 'skippingnonbases' and 
>> 'unambiguous' ?
> Basically they're the same thing, and yes, we should rename them to be 
> similar I think...
>

That's what I also thought. My vote would go to unambiguous (a PITA to 
spell, though), it sounds like that's what's used the most, eg in the 
symbol plists.  I guess you and John have a better view on this.


- Koen.