[Biococoa-dev] Using an untyped class sequence

[Alexander Griekspoor]

I agree that in some cases tools are the way to go, but one of the  
things I dislike most of the biojava project (and I remember from  
previous discussions that I was not alone) is in fact that you can't  
do a thing without needing a bunch of helper, factory, and/or tool  
objects. Please, let us stay far from that. It's really un-cocoa  
like, imagine NSString and you would need a "exporter tool" to save  
it to file, a "converter tool" to return it in a different encoding  
etc etc. Help!!

> BCSequenceTool -> MW, ...
> BCProteinTool -> pI, digest, ...
> BCDNATool -> translate, ...
> BCRNATool -> transcribe, ...

Please not, the names of these tools alone are terrible!!!! I agree  
that for some relatively difficult things like a translation, digests  
or alignments, we need a tool, but even then I would like to have  
convenience methods that do the job of creating and handling the tool  
object in the background. For the rest, a simple MW should be one  
call and not need a tool! And IF we need a tool, make it specialized:  
BCDigester or what else instead of BCSequenceTool.

Alex

On 6-jul-2005, at 0:35, Koen van der Drift wrote:

>
> On Jul 5, 2005, at 12:32 PM, Charles Parnot wrote:
>
>
>> My bottom line is the following:
>> * it seems we should keep the subclass structure no matter what;  
>> and because Koen's concern has been addressed, he might agree with  
>> that... Koen? ;-)
>>
>
> My main reason for liking the single class so much is that it is  
> easy to maintain and allows a high degree of modularity. Indeed the  
> code duplication has been addressed in great extent and I am sure  
> that everyone can agree that this makes maintenance of the sequence  
> classes much easier. However, when adding stuff into the  
> superclass, we always need to be aware of the fact that the code  
> needs to be adapted for one or more subclasses.
>
> What I also like a lot is that most functionality is kept is small  
> 'Tools' classes. We already made a start with that and it seems to  
> work nice (at least for me ;-)
>
> Now there are (at least) two ways to call the tools classes:
> 1. We put sequence-specific wrappers in the subclasses (more or  
> less our current approach)
> 2. We create a general tools class for DNA, RNA, Protein, that  
> contains wrappers to various tools classes, again sequence-specific  
> (biojava approach):
>
> BCSequenceTool -> MW, ...
> BCProteinTool -> pI, digest, ...
> BCDNATool -> translate, ...
> BCRNATool -> transcribe, ...
>
> So for instance, [BCSequenceTools translation] does not exist, so  
> will never compile. In these cases, call BCDNATools to take care of  
> the operation. Another example, BCProteinTool should only contain  
> wrappers that calls the specific tool., so eg:
>
> pI = [BCProteinTool isoElectricPoint forSequence: mySeq]
>
> Now if mySeq is not a protein, then display a console message, plus  
> return a reasonable value. If we document this well, there  
> shouldn't be a problem. These things can always happen, also when  
> using typed sequences. I think it is fine if we leave some  
> responsibility with the user of the framework. They don't want  
> their program to misbehave so will be sure to catch these type of  
> errors.
>
>
>> * except me, it seems everybody is confused by the placeholder  
>> class BCSequence; the idea was to try to have both options  
>> (BCSequence or the bunch of typed sequences), and decide at some  
>> point to dump one of the two or maybe keep both; it seems the  
>> consensus is now to dump one of the two, and based on the above,  
>> it seems logical to dump BCSequence; this is OK, there is very  
>> little code in there anyway, it was not very much work; just  
>> please keep it around a little while, I will archive it somewhere  
>> on my hard-drive (I don't want to rely only on the CVS server!!).  
>> And if we ever want to switch back to a single public class, it  
>> would not be very much work; the existing class structure would be  
>> easily amenable to a class cluster.
>>
>
> So what will we be using instead then?
>
> - Koen.
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>
>

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

           LabAssistant - Get your life organized!
           http://www.mekentosj.com/labassistant

*********************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20050706/f0857f29/attachment.html>