[Biococoa-dev] more ramblings
Koen van der Drift
kvddrift at earthlink.net
Fri Dec 3 17:17:25 EST 2004
>> 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
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
>>> 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.
More information about the Biococoa-dev