[Biococoa-dev] more ramblings

[Alexander Griekspoor]

Op 3-dec-04 om 23:17 heeft Koen van der Drift het volgende geschreven:

>>> 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).
Ok, but then it can in principle handle general BCSequences as well ;-)

> 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.
I think we just have to keep the general setup the way it is now, and 
see how things and up after a while, perhaps it might prove wise to 
switch to the single BCSequence class in the end.
>
> 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.
That's my favorite as well...
>
> BTW, anyone oppose if I cleanup BCSequence and it's subclasses, and 
> add convenience methods?
Nope

> 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?

Please indeed use the common prefixes wherever possible, but this comes 
down to the same thing as I raised forward for this discussion:

> - (BCSequenceType *) guessSequenceTypeFromString: (NSString *) string;
> - (BCSequence *) guessSequenceFromString: (NSString *) string;
> Sometimes, you just want to know the type instead of getting the 
> sequence back. In the documentation we can point the reader to the 
> fact that if he want to have the sequence, there's the other method 
> (and thus prevent him to do double work). Now I'm in the nitpicking 
> mode anyway, the method name guidelines suggest to do something like:
>
> sequenceTypeForUntypedString: or sequenceTypeForUnknownString:
> and
> sequenceFromUntypedString: or sequenceFromUnknownString:
>
> The originals don't suggest that something is returned...

methodnames should include the things they return (IF they return 
something of course), so if you would have findSubstring it wouldn't 
make sense, and actually neither really does findRangeOfSubstring: but 
I could live with the latter...

>>>> 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.
True

>
>> (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.
Ok, feel free to add it...
>
>
>>> 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.
Unambiguous is nicer, but perhaps in this case strict is more 
practical, and would be my choice..
Alex

*********************************************************
                     ** Alexander Griekspoor **
*********************************************************
               The Netherlands Cancer Institute
               Department of Tumorbiology (H4)
          Plesmanlaan 121, 1066 CX, Amsterdam
                   Tel:  + 31 20 - 512 2023
                   Fax:  + 31 20 - 512 2029
                   AIM: mekentosj at mac.com
                   E-mail: a.griekspoor at nki.nl
               Web: http://www.mekentosj.com

                           Windows vs Mac
	65 million years ago, there were more
                      dinosaurs than humans.
	     Where are the dinosaurs now?

*********************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4785 bytes
Desc: not available
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20041203/9cf2a96f/attachment.bin>